[Wildcard Variables] Analysis Server Implementation

[kallentu]

This issue tracks all the analysis server work items for the wildcard variables feature. Referenced from: https://github.com/dart-lang/sdk/blob/main/pkg/analysis_server/doc/process/new_language_feature.md

• [x] Call Hierarchy
  • Tests needed.
    • No crashes
    • Maybe should show no callers.
    • One for each direction.
    • Local function called _ should show all the things that call that function.
    • Might need to have a check that nobody can call it.
• [x] Closing Labels
  • Test to make sure it doesn't crash.
    • Invoke something that doesn’t exist.
• [x] #56361
  • Tests needed, work needed
    • Don’t want to suggest wildcards that can’t be referenced.
    • Test the situations for binding _ to make sure it still works. (Top level declarations, fields, etc)
    • Test import prefix named _ -> still nonbinding but can access extensions
    • @override works correctly with wildcards.
• [x] #56009
  • Tests needed
    • Make sure that local functions named _ can still be folded
• [x] Document Symbols https://github.com/dart-lang/sdk/commit/a9ec266732df38a200f8386f6138dbd26478e420
  • Tests needed, work needed
    • Do we want local functions with a name of _ to show up in the outline view?
      • Yes. It’s there whether we want to call it or not.
      • Then test that they are behaving the way we want them to.
    • Do we want to see the nested local functions too?
      • If we include them, make sure to test that two can show up at the same time, as they would have the same name.
• [x] Document Colors
• [x] Flutter Outline
• [x] Hovers
  • Work needed, tests needed
    • Make decision on what we want to show up
      • Do we want a special message that it’s a wildcard variable?
    • Test that it is as expected
• [x] Implemented Markers
  • Test that it works for _ named methods and classes.
• [x] Inlay Hints
  • Tests needed, work needed
    • Nothing is broken
    • UX decision - what do we want to show for inlay hints?
      • Parameter names
      • var _ = 1
• [x] Navigation - legacy
  • Test on a wildcard variable and try to navigate, don’t crash.
• [x] Navigation - LSP Go to Definition
  • Test needed - no crashes.
    • super._ and this._ works as intended
• [x] Navigation - LSP Go to Type Definition
  • Test needed - no crashes.
    • Should do nothing.
• [x] Navigation - Go to Super
  • Test needed - no crashes.
    • _ methods don’t crash, should go to the correct destination.
• [x] Occurrences - legacy
  • Tests needed - no crashes
    • Make sure field _ works with their references
    • Clicking on field & clicking on their references
• [x] Occurrences - LSP Document Highlights
  • Tests needed - no crashes
    • Make sure field _ works with their references
    • Clicking on field & clicking on their references
• [x] Organize Imports
  • Tests needed - no crashes.
• [x] Outline
  • See above (Outline - Document Symbols)
• [x] Overrides Markers
• [x] Search - Find References
  • Tests needed
    • Make sure field/method named _
    • Local var with _ has error, but still can find it?
    • Make sure it's working correctly when we opt out too.
    • Pre/post wildcard behaviour.
• [x] Search - Implementations - LSP
• [x] Search - Member Declarations
• [x] Search - Member References
• [x] Search - Top-level Declarations
• [x] Selection Range
• [x] Syntax Highlighting
  • [x] Semantic Highlights
  • [x] LSP Semantic Tokens
• [x] Signature Help
  • Tests needed (https://github.com/dart-lang/sdk/commit/10cbc8f9b37f408b7aa927181421c3dd4a8573c1)
    • Parameters named _ show up correctly.
    • Parameter still has a type.
• [x] Snippets
• [x] Sort Members
• [x] Type Hierarchy - legacy
• [x] Type Hierarchy - LSP
• [x] Workspace Symbols

Larger Tasks

These need to be audited one at a time and asked the following:

1. Do we need anything new?
2. How many previous ones broke or need changing?

Potentially make an issue for each one.

• [ ] Quick Assists
• [ ] Quick Fixes
  • [ ] #56581
  • [x] #56221
  • [x] #55965
  • [x] #55980
  • [x] #56582
  • [ ] #55738
• [ ] #56567
  • Consider highlighting wildcards specially (see discussion)
• [ ] Refactorings - legacy
• [ ] Refactorings - self describing
• [ ] Rename refactoring
  • Make sure the rename works correctly (What is correct?)
  • If someone has parameter named _ and they try to reference it
    • Do we want to offer refactoring to rename this _?
      • Probably yes.
    • Still resolve the non-binding variable, but give error
  • If we have a field named _, ref will be bound the the field
    • Maybe quick fix that says rebind it to local?
  • Or two non-binding parameters
    • Ambiguous, which one?

[pq]

Closing Labels Test to make sure it doesn't crash. Invoke something that doesn’t exist.

@bwilkerson (or anyone), thoughts on what we're hoping to test here?

[bwilkerson]

No, I can't think of anything. As far as I can remember, we only create a closing label for invocations of constructors, and constructor invocations aren't impacted by this language feature.

[kallentu]

Closing for now. We seem to be done the work in this area. If there are emerging issues or feature requests, we can reopen.