Brian Wilkerson
f92ea3d58d
I don't have a lot of confidence that the data being collected is what needs to be collected in each of these cases, but I believe that I've correctly identified the visit methods that need to be collecting data. I think we need to have a test that ensures that the keys being used in this table generator are the same as the keys being used by the relevance feature computer (as computed by the in-scope pass). I don't know exactly what that test would look like, but that would ensure that (a) the keys are the same and (b) the table generator isn't missing keys being used by the completion engine or collecting data that isn't being used. I also fixed a bug that prevented this generator from running and tested to ensure that it could run over several example packages. Change-Id: I0c0cff148d288942e39ee876e89cdf9d1468f59d Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/473780 Commit-Queue: Brian Wilkerson <brianwilkerson@google.com> Reviewed-by: Samuel Rawlins <srawlins@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.