[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

• 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.
• Closing Labels
  • Test to make sure it doesn't crash.
    • Invoke something that doesn’t exist.
• [Wildcard Variables] Code Completion Support #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.
• [Wildcard Variables] Add Code Folding tests #56009
  • Tests needed
    • Make sure that local functions named _ can still be folded
• Document Symbols a9ec266
  • 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.
• Document Colors
• Flutter Outline
• 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
• Implemented Markers
  • Test that it works for _ named methods and classes.
• Inlay Hints
  • Tests needed, work needed
    • Nothing is broken
    • UX decision - what do we want to show for inlay hints?
      • Parameter names
      • var _ = 1
• Navigation - legacy
  • Test on a wildcard variable and try to navigate, don’t crash.
• Navigation - LSP Go to Definition
  • Test needed - no crashes.
    • super._ and this._ works as intended
• Navigation - LSP Go to Type Definition
  • Test needed - no crashes.
    • Should do nothing.
• Navigation - Go to Super
  • Test needed - no crashes.
    • _ methods don’t crash, should go to the correct destination.
• Occurrences - legacy
  • Tests needed - no crashes
    • Make sure field _ works with their references
    • Clicking on field & clicking on their references
• Occurrences - LSP Document Highlights
  • Tests needed - no crashes
    • Make sure field _ works with their references
    • Clicking on field & clicking on their references
• Organize Imports
  • Tests needed - no crashes.
• Outline
  • See above (Outline - Document Symbols)
• Overrides Markers
• 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.
• Search - Implementations - LSP
• Search - Member Declarations
• Search - Member References
• Search - Top-level Declarations
• Selection Range
• Syntax Highlighting
  • Semantic Highlights
  • LSP Semantic Tokens
• Signature Help
  • Tests needed (10cbc8f)
    • Parameters named _ show up correctly.
    • Parameter still has a type.
• Snippets
• Sort Members
• Type Hierarchy - legacy
• Type Hierarchy - LSP
• 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
  • [wildcards] Consider quick fix: convert UNUSED_ELEMENT to wildcard #56581
  • [wildcards] Quick fix for dead late wildcard variable initializers #56221
  • [wildcards] Quick fix: convert UNUSED_LOCAL_VARIABLE to wildcard #55965
  • [wildcards] Consider quick fix: convert UNUSED_CATCH_CLAUSE to wildcard #55980
  • [wildcards] Consider quick fix: convert UNUSED_CATCH_STACK to wildcard #56582
  • [wildcards] Consider reporting UNUSED_CATCH_STACK for stack wildcard params #55738
• [wildcards] Semantic Highlighting - consider styling wildcards #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.