[Dot Shorthands] Analysis Server Implementation

[kallentu]

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

• [x] 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.

• [X] 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

• [X] Code Folding

  • Should still work, but unsure if we want to test this.

• [X] 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

• [x] Hovers (a legacy protocol feature, only available to IntelliJ and Android Studio)

  • If we have a new AST, needs work

• [X] 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

• [X] 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

• [X] Inlay Hints (an LSP feature allowing extra information to be displayed using inline hints)

  • No work expected

• [x] Go to Definition (LSP feature)

  • Should still work, perhaps test and add behaviour if it doesn’t work.

• [x] 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

• [x] Go to Super (LSP feature)

  • No work needed

• [x] Legacy protocol (for IntelliJ and Android Studio)

• [x] Occurrences

  • [x] Legacy protocol (for IntelliJ and Android Studio)

• [x] Document Highlights (LSP feature)

  • Should still work, perhaps test and add behaviour if it doesn’t work.

• [X] Organize Imports No work needed

• [X] 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.
  • [X] LSP self-describing refactorings

• [ ] Quick Assists

  • TODO

• [ ] Quick Fixes

  • 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 and Create getter (considering it can be followed by non-assignment selectors from the feature specification - Elevator pitch - third paragraph, we won't need to make Create 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 as Go to Definition, etc. commands).

• [ ] Extract expression

  • When we extract it, might not have context anymore.

• [ ] https://github.com/dart-lang/sdk/issues/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

  • [x] Find References
    • Should still work, perhaps test and add behaviour if it doesn’t work.
  • [X] Implementations - LSP
    • No work needed
  • [X] Member Declarations
    • No work needed
  • [ ] Member References
  • [x] Top-level Declarations
    • No work needed

• [x] Selection Range (an LSP feature allowing a selection to be expanded to cover the range of an ancestor AST node)

• [x] Syntax Highlighting

  • [x] Legacy protocol, a.k.a. Semantic Highlights (for IntelliJ and Android Studio)
  • [x] Semantic Tokens (LSP feature)
    • Should still work
    • Tests.

• [X] Signature Help (an LSP feature that tells the parameters and types needed for an invocation)

  • Will just work probably?

• [X] Snippets No work needed

• [X] Sort Members

  • [X] Type Hierarchy
  • [X] Legacy protocol (for IntelliJ and Android Studio)
  • [X] LSP feature
    • No work needed

• [X] Workspace Symbols (LSP feature) No work needed

[FMorschel]

About the quick fixes, we probably would need to add some test cases for Import Library fixes, Add enum constant, Create method and Create getter (considering it can be followed by non-assignment selectors from the feature specification - Elevator pitch - third paragraph, we won't need to make Create Setter work for this).

We should also take a look at Go to Import (same place as Go to Definition, etc. commands).

---

If I missed/forgot anything please let me know.

PS: @kallentu the inner list items are not [ ] or -/* if that is something you'd like to fix.

[kallentu]

Thank you. Fixed up the original issue and then added your suggestions. Will come back to look at this when I'm doing the server implementation.

[FMorschel]

One more note @kallentu - I've not looked at what you've already done yet, so if you've seen this feel free to ignore it.

We have three ways to create method, one at create_method.dart, another at create_method_or_function.dart (or the other way around, not at my computer right now - this one handles tearoffs - I'll open an issue once I finish a refactor there to ask to merge them) and another at create_extension_member.dart (another getter here too).

[kallentu]

One more note [@kallentu](https://github.com/kallentu) - I've not looked at what you've already done yet, so if you've seen this feel free to ignore it.

We have three ways to create method, one at create_method.dart, another at create_method_or_function.dart (or the other way around, not at my computer right now - this one handles tearoffs - I'll open an issue once I finish a refactor there to ask to merge them) and another at create_extension_member.dart (another getter here too).

Good point, I'll be sure to look at all of them and see what we need to add. I haven't gotten to this yet, but I'll add this comment to the first post since that's the one I refer to and update.

[RohitSaily]

dot-shorthands related analysis issue: #61209

[FMorschel]

I think everything is in order here @kallentu . Unless something is missing from completion, (which I seem to recall seeing an issue or commit for) or you remember anything else.

[kallentu]

I think everything is in order here [@kallentu](https://github.com/kallentu) . Unless something is missing from completion, (which I seem to recall seeing an issue or commit for) or you remember anything else.

Yep! I think I have one last CL to fix code completion for const .^, but otherwise it's ready to close.

I'll close it once that CL is in. And then dot shorthands is done as far as the implementation goes.