Description
This issue tracks all the analysis server work items for the dot shorthands feature. Referenced from: https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/doc/process/new_language_feature.md
Estimated work
-
Call Hierarchy (an IDE feature where you can get a call hierarchy if you click on a method)
The shorthand calls should show up properly in the call hierarchy.- At least tests.
-
Closing Labels (an LSP feature allowing the IDE to show lightly grayed out comments at the end of the last line of a multi-line invocation, to aid the user in understanding what invocation is closed by a ))
- No work needed
-
Code Completion
Code completion should work when entering . in a place where there is a context type available.- Should work well, this is the selling point of the entire feature.
- If we noted that we looked in a certain class from the
ResolverVisitor
, code completion can pick that info up - Otherwise, the code completer has to do that
-
Code Folding
- Should still work, but unsure if we want to test this.
-
Document Colors (an LSP feature whereby a reference to a color in code can be associated with a colored swatch and a color picker)
- No work needed
-
Hovers (a legacy protocol feature, only available to IntelliJ and Android Studio)
- If we have a new AST, needs work
-
Implemented Markers (allows navigation from a base class method to methods that override it, or from a base class to classes that extend/implement it)
- No work needed
-
Override Markers (allows navigation from a method to the base class method it overrides, or from a class to the class that it extends/implements)
- No work needed
-
Inlay Hints (an LSP feature allowing extra information to be displayed using inline hints)
- No work expected
-
Go to Definition (LSP feature)
- Should still work, perhaps test and add behaviour if it doesn’t work.
-
Go to Type Definition (LSP feature)
- “If we have a reference to a static field, then this should go to the type of the field. We need to ensure that the feature isn't dependent on the 'target' of the expression.” - Brian
-
Go to Super (LSP feature)
- No work needed
-
Legacy protocol (for IntelliJ and Android Studio)
-
Occurrences
- Legacy protocol (for IntelliJ and Android Studio)
-
Document Highlights (LSP feature)
- Should still work, perhaps test and add behaviour if it doesn’t work.
-
Organize Imports
No work needed -
Outline
Flutter Outline
Legacy protocol, a.k.a. Document Symbols (for IntelliJ and Android Studio)
LSP feature
No work needed, nothing added top level? -
Refactorings and quick assists/fixes (note that in addition to potentially creating new refactorings and/or quick assists/fixes, part of the work required to implement a new language feature includes evaluating each existing refactoring and quick fix/assist to see whether it needs to be improved or have test cases added to reflect the new feature).
- Legacy refactorings (for IntelliJ and Android Studio)
- LSP rename refactoring (note that LSP has a special protocol for renames)
- If renaming a method or name in the shorthand, should update as well.
- LSP self-describing refactorings
- [Dot Shorthands] Analysis Server - Assists #60957
- [Dot Shorthands] Analysis Server - Quick Fixes #60994
- Evaluate existing quick fixes
- Add quick fix to remove type when context type is obvious?
- Remove/add explicit type for the shorthand?
prefer_dot_shorthands
- Contributed by @FMorschel : Add some test cases for
Import Library
fixes,Add enum constant
,Create method
andCreate getter
(consideringit can be followed by non-assignment selectors
from the feature specification - Elevator pitch - third paragraph, we won't need to makeCreate Setter
work for this). - Contributed by @FMorschel : We have three ways to create method, one at create_method.dart, another at create_method_or_function.dart and another at create_extension_member.dart (another getter here too).
- We should also take a look at
Go to Import
(same place asGo to Definition
, etc. commands).
- Extract expression
- When we extract it, might not have context anymore.
-
[Dot Shorthands] Analysis Server - Linter Meta Issue #60893
- Need to evaluate existing lints (Est. 1 week of work?)
- Are there any best practices we want to enforce?
- Lint on repetitive type where one can use a shorthand? (see: quickfix)
-
Search
- Find References
- Should still work, perhaps test and add behaviour if it doesn’t work.
- Implementations - LSP
- No work needed
- Member Declarations
- No work needed
- Member References
- Top-level Declarations
- No work needed
- Find References
-
Selection Range (an LSP feature allowing a selection to be expanded to cover the range of an ancestor AST node)
-
Syntax Highlighting
- Legacy protocol, a.k.a. Semantic Highlights (for IntelliJ and Android Studio)
- Semantic Tokens (LSP feature)
- Should still work
- Tests.
-
Signature Help (an LSP feature that tells the parameters and types needed for an invocation)
- Will just work probably?
-
Snippets
No work needed -
Sort Members
- Type Hierarchy
- Legacy protocol (for IntelliJ and Android Studio)
- LSP feature
- No work needed
-
Workspace Symbols (LSP feature)
No work needed