Paul Berry
0519debc2c
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>
analysis_server
A long-running process that provides analysis results to other tools.
The analysis server is designed to provide on-going analysis of one or more code bases as those code bases are changing.
Using the server
The analysis server is not intended to be used stand-alone, and therefore does not have a human-friendly user interface.
Clients (typically tools, such as an editor) are expected to run the analysis
server in a separate process and communicate with it using a JSON protocol. The
original protocol is specified in the file analysis_server/doc/api.html
and Language Server Protocol support is documented in
tool/lsp_spec/README.md.
Features and bugs
Please file feature requests and bugs at the issue tracker.