Previously, diagnostic codes were generated into libraries. This led
to a proliferation of imports of those generated libraries throughout
the analyzer and analysis server codebases, since the analysis server
didn't know that it should suggest adding imports of the correspinding
non-generated libraries instead.
I tried to fix that problem by marking each generated diagnostic code
library as deprecated, and ignoring the deprecation warning at the
site where the corresponding non-generated file imports it. But this
led to a different problem: it prevented code completion from
suggesting elements that came from the generated libraries. In my work
toward replacing the analyzer's error reporting API with a more
literate API (e.g. `reportError(errorCode.withArguments(...).at(...))`),
I've discovered that the lack of code completion makes the more
literate API much harder to use.
This CL changes the code generator so that diagnostic codes are
generated into part files. This neatly prevents unintentional imports
of the generated files without having to do any tricks with
deprecation.
A side benefit of this change is that the code generators no longer
need complex logic to determine which `import` directives to generate,
since the import directives live in the non-code-generated parent
library.
Note that in the past, the analyzer code base has heavily discouraged
the use of part files. I think they are justified in this case,
because the files are generated; if it were not for the desire to code
generate these files, we would fold them straight into the libraries
they are parts of.
Change-Id: I6a6a6964a375ee81f9580b354766bd041c83b3cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445480
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Paul Berry
0519debc2c