Konstantin Shcheglov
3d95c84db5
Introduce the internal `analyzer_element_model_tracking` lint to enforce explicit tracking annotations on analyzer element-model members. This codifies how each member contributes to IDs, dependency tracking, and incremental analysis. Rule behavior (applies to classes annotated with `@elementClass`): - Public instance **fields** must be annotated with `@trackedIncludedInId`. - Public instance **getters/methods** (non-abstract, non-void) must have exactly one of: `@trackedDirectly`, `@trackedDirectlyExpensive`, `@trackedDirectlyOpaque`, `@trackedIncludedInId`, or `@trackedIndirectly`. - Flags invalid annotations on ineligible members (constructors, setters, static or private members). - Reports when more than one tracking annotation is present. - Reports when a required annotation is missing. Wire-up: - Add lint codes and names: - `analyzer_element_model_tracking_bad` - `analyzer_element_model_tracking_more_than_one` - `analyzer_element_model_tracking_zero` - Mark these as `noFix` in error-fix status and enable the rule in `analysis_options.yaml`. - Register the rule in the linter. Model updates: - Annotate many members in `element.dart` to reflect their tracking category (e.g. `@trackedIncludedInId` for identity-affecting members; `@trackedDirectlyExpensive` for lazily computed collections). - For opaque surfaces where precise tracking is impractical (e.g. `documentationComment`, `nonSynthetic`, `session`, member lookups, ancestor queries, `visitChildren`), record usage via `globalResultRequirements?.recordOpaqueApiUse(...)`. Why: - Makes dependency/ID semantics explicit and reviewable. - Improves correctness of incremental and cache invalidation behavior. - Establishes a foundation for refining precision over time without regressions. Scope: - Internal only; no public API changes. Change-Id: Id2beaf5ead35b8a361bc1b7688ccb5b5a74afe88 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/446140 Reviewed-by: Paul Berry <paulberry@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.