You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make analysis server/IDEs show the distinction between fields and getters accurately and consistently #55956
In Dart-Code/Dart-Code#5011 it was highlighted that in some places in VS Code (via LSP) we are inconsistent about when we map things to a "Property" kind vs a "Field" kind. In some places (for example code completion) we use "Field" where the static type has an implicit getter that just points at a field, but in others (like semantic tokens) we do not.
We feel the right thing to do here is to follow the language accurately, so when something is a reference to a getter, we should always show it as such (a "Property" in LSP) even if in the static type it's just a field. Showing something as a Field is inconsistent with the spec and could lead to incorrect assumptions (since it could actually be an overridden getter at runtime).
For LSP, this means we should only map to the "Field" kinds for actual references to fields (like constructor initializers, field formals, and the field declaration in something like document outline) and other places (semantic tokens, hovers, code completion) should use "Property".
(@jwren I suspect all changes here are either LSP-specific, or in base server functionality that will be updated in order to fix this for LSP, but FYI just in case there might be things in the IntelliJ plugin that might need reviewing).
Activity
[analysis_server] Add a semantic token modifier to wildcards
DanTup commentedon Nov 13, 2025
I think this might be done (at least for LSP), but I'll take another look through the mappings to see if I can find anything.
It probably make senses to also add some explicit notes on this to https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/doc/design/principles/language_fidelity.md so it's captured centrally instead of just in this issue (and related CLs).
DanTup commentedon Dec 3, 2025
Closing this as I can't see any places where we're not doing the right thing now, and the intentions are clearly documented in the doc above.