Konstantin Shcheglov
ba666c8082
Replace the generic mutable reference tree with typed reference classes for roots, libraries, top-level declarations, member containers, members, and built-in elements. The previous API was shallow. It offered a small primitive, `getChild(String)`, but pushed too much knowledge to every caller: which sentinel names exist, which paths are valid for each declaration kind, which references may contain members, and which references are not real declarations at all. That kept the reference implementation simple by spreading its complexity across the analyzer. Make the reference model deeper instead. Callers now ask for the semantic role they need, such as a library, constructor, method, field, or top-level declaration. The reference layer owns the representation, lookup, creation, and serialization details. This concentrates the complexity behind a narrower interface, makes the common cases clearer, and makes invalid reference shapes harder to construct. This is a strategic cleanup rather than a local simplification. The reference graph is used by element construction, summary reading and writing, scopes, exports, and fine-grained dependency manifests. Giving it explicit concepts reduces the amount of convention each subsystem must remember and preserves a simpler mental model at the call sites. Update summary serialization to write semantic reference rows with a tag, enclosing reference, kind, key, and URI payload. Bump the analyzer data version because this changes the linked summary format. Represent exported declarations as export entries that carry the exported name, reference, and export locations. Use those entries when building scopes, filtering deprecated exports, and updating fine-grained library manifests. Keep import prefixes out of the declaration reference tree. Bind prefix fragments through fragment-local ids so prefixes can be restored and merged without fabricating declaration references. Bug: https://github.com/dart-lang/sdk/issues/63227 Change-Id: If28f8b779faa78bdf023bc69b714555fae57ccb3 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/497621 Reviewed-by: Johnni Winther <johnniwinther@google.com> Reviewed-by: Samuel Rawlins <srawlins@google.com> Commit-Queue: Konstantin Shcheglov <scheglov@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.