Paul Berry
d0849997cc
A mechanism is added to allow the types of diagnostic arguments to be checked at runtime. This mechanism is enabled for all analyzer diagnostic codes except for syntactic errors (since those are generated by the shared parser using the CFE's argument substitution mechanism, which is already strongly typed). To avoid introducing backwards incompatibilities to analyzer clients, the types are only checked at runtime if the diagnostic code implements the new `DiagnosticCodeWithExpectedTypes` interface. The expected types are determined by the type annotations in the `messages.yaml` file. These are the same type annotations used in the new literate API for diagnostic error reporting. So this should ease the transition into the new literate API, which will make any such type errors into compile-time errors. Change-Id: I6a6a696473f1d75686ba4405a1bef1e978d88993 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/445785 Commit-Queue: Paul Berry <paulberry@google.com> Reviewed-by: Johnni Winther <johnniwinther@google.com> Reviewed-by: Brian Wilkerson <brianwilkerson@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.