Konstantin Scheglov

Fix for the analyzer: https://dart-review.googlesource.com/c/sdk/+/335383

FYI, in the analyzer we: 1. Don't create the synthetic default constructor until after the declarations phase. So, if an actual constructor is added, we don't add the default one....

I don't like re-inferring, it does not fit well with the current analyzer implementation. Maybe disable private field promotion when the are macro applications in the library?

> It ends up being quite complicated to support well because of the invalidation semantics that are implied. Any function invoked at compile time invalidates anything that depends on it...

Do you worry that using declarations from `dart:core` is hard to do when you are implementing a macro, or that the code generated in result is full of import prefixes?...

We have to use `Identifier` because there might be another macro, that you don't know of, applied to the same library, and it adds `class int {}`.

> And come augmentations, it will only apply to the fully augmented declaration, not the individual steps. When you say "fully augmented declaration", how does this reconcile with "The function...

In the analyzer we run all 3 phases during linking summaries, because even the definitions of the macro-generated library augmentation are based on elements, and so the whole code of...

To me "library augmentation" sounds consistent. It falls into the same patterns as "class augmentation". AFAIK "augment" is not proper noun? So, as I understand English, `import augment` should be...

> Personally I think that is the correct choice, because I _do_ think they are a part of the API contract - at least sometimes. For instance if I have...