Introduce a DiscardSyntaxClassifier

[lameox]

fixes #39768 .

This is my first contribution so please let me know if there is anything else needed apart from the exported highlighter or if there is a better place in the codebase to introduce the changes.

[dnfclas]

All CLA requirements met.

[CyrusNajmabadi]

hi @lameox thanks for the contribution!

[CyrusNajmabadi]

should be impossible to hit this. we should throw here.

[CyrusNajmabadi]

can use a switch expression here as well.

[sharwell]

Since this is argument syntax (as opposed to parameter syntax), wouldn't this be hit for most arguments?

[lameox]

Yeah i think so. This is why I originally used AbstractKeywordHighlighter instead of AbstractKeywordHighlighter<ArgumentSyntax> and overwrote IsHighlightableNode so GetHighlightsForNode only got called for the required types of nodes. However it was suggested I should use AbstractKeywordHighlighter<ArgumentSyntax> which unfortunately seals IsHighlightableNode. Therefore this code always executes and I need to return the empty enumerable.

[CyrusNajmabadi]

I'm not seeing how this woudl be subtantively different. Both cases need to check all nodes to see if they should run against them.

[CyrusNajmabadi]

ther's a different baseclass you can subclass right? where you can specify through a type argument that you are constrained to ArgumentSyntax right?

[CyrusNajmabadi]

yes, it's AbstractKeywordHighlighter<ArgumentSyntax>.

[CyrusNajmabadi]

Can be simplified

[CyrusNajmabadi]

Switch to typechecks

[lameox]

done

[CyrusNajmabadi]

Lgtm

[CyrusNajmabadi]

@jinujoseph can we get a buddy for this community pr? Thanks!

[sharwell]

💡 Can use pattern matching here:

if (node.Expression is IdentifierNameSyntax { Identifier: { Text: "_" } } nameSyntax)

[lameox]

I still need to get used to pattern matching tbh. Should all new code aim to make use of pattern matching or is it up to preference?

[CyrusNajmabadi]

It's up to preference. in some places it works nicely (like here), in others, it can feel more forced/unpleasant.

[sharwell]

Since this is argument syntax (as opposed to parameter syntax), wouldn't this be hit for most arguments?

[sharwell]

💡 Should add a test showing that this does not highlight the argument if you write it as @_. This token has the same ValueText as _, but different Text, and in this case the difference is meaningful.

[lameox]

Added tests covering that case.

[CyrusNajmabadi]

c

[JoeRobich]

LGTM

Can you add a test for _ = int.Parse("");?

[lameox]

@JoeRobich Sure thing. This uncovered the missing case for VariableDeclaratorSyntax. From what i can tell i don't actually need symbols for those and can just check the Identifier for _.

Another thing i was kind of suprised about was the test for

 _ = int.Parse("");

In this case we get the following symbol classifications:

Keyword "_"
Static "Parse"
Method "Parse"

This is in contrast to all other tests where the order of the Static "Parse" and Method "Parse" is reversed. For now i just reversed the expected order in the test but this seems kind of fishy to me. Should i keep it like that or investigate further?

[JoeRobich]

Should i keep it like that or investigate further?

@lameox Leave it as is. We are likely to make some changes with regards to the Static classification in 16.6.

[lameox]

Close and reopen to trigger retest

[JoeRobich]

Thanks @lameox!