Semantic highlighing doesn't differentiate parameter passing by its name from usage inside the function

[Bobronium]

Issue Type: Bug

1. Use a keyword argument in decorator like so: @f(foo=None)
2. Use a keyword argument in regular function cal like so: f(foo=None)
3. Observe that foo is highlighted as a parameter by semantic token highlighting in #1, and not highlighted in #2

Expected behaviour: foo in #1 either should not be reported by semantic highlighting (consistent with #2) or reported differently, e.g. variable.parameter.

Extension version: 2022.9.11611009 VS Code version: Code 1.67.2 (Universal) (c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5, 2022-05-17T18:20:57.384Z) OS version: Darwin arm64 21.5.0 Restricted Mode: No

[heejaechang]

@Bobronium can you share actual code that we can use to test? and result of "inspect editor tokens and scopes" for each case?

I see all shows same variable.parameter and show right coloring.

are you saying it should not mark as parameter?

[Bobronium]

@heejaechang, I'm saying a) behaviour should be consistent across any calls, b) if parameter is market, there should be an indicator that it's a keyword argument.

[Bobronium]

Ok, it's even bigger than that. I think something may have changed in latest releases since I haven't noticed this before.

Pylance marks parameter_name as parameter on both line 2 and line 4, as they're the same thing. But they're not. On line 2 parameter is used inside the function as a local variable. On line 4, parameter is passed to the function by its name. Two completely different cases, and textmate does recognize them and mark them differently.

This is how I expect it to look like and how it looks like without semantic highlighting enabled:

[Bobronium]

I would've just disabled parameter scope highlighting, but it gives recognition for things such as overriding builtin types.

Semantic highlighting disabled

Semantic highlighting enabled

This behaviour would suit my needs: textmate does a good job at recognizing keyword arguments when semantic highlighting doesn't stand in its way:

[debonte]

In this example, line 8 is calling __call__ on an instance of _lru_cache_wrapper.

To get declaration types, SemanticTokenProvider._getNameNodeToken calls TypeEvaluator.getDeclarationsForNameNode which currently only handles arguments passed to functions, overloads, and class constructors, not __call__ methods on instances.

[debonte]

Here's a somewhat hacky prototype I did to prove that enhancing TypeEvaluator.getDeclarationsForNameNode fixes the user's scenario. I'm not sure how to best support the kwargs scenario. https://github.com/debonte/pyrx/commit/e56f958f65f4621e9b01a3f8ee3f1e9d85866c4f