reportUndefinedVariable diagnostic in named decorator parameters with semantic highlighting enabled

[zgoda]

Environment data

• Language Server version: 2020.9.0
• OS and version: Linux Ubuntu 20.04 x86_64
• Python version (& distribution if applicable, e.g. Anaconda): 3.8.5, Anaconda

Expected behaviour

autouse is recognised as valid pytest.fixture() argument

Actual behaviour

"autouse" is not defined message in problems output

Code Snippet / Additional information

    @pytest.fixture(autouse=True)
    def _set_up(self, mocker):
        fake_connparams = {
            'username': 'test-user',
            'password': 'test-password',
            'host': 'test-host',
            'port': 1234
        }

[zgoda]

Also, 2020.9.0 made the colours in One Dark Pro theme just crazy.

[zgoda]

323 has more on this crazy code highlight, even with the same colour scheme.

[jakebailey]

We can talk about the highlighting on that issue (disable semantic highlighting if you don't like it), but the squiggle on the parameter looks to be a diagnostic bug.

[jakebailey]

Does the diagnostic go away if you disable semantic highlighting? E.g. disable it for all files or just Python:

{
    "editor.semanticHighlighting.enabled": false
}

{
    "[python]": {
        "editor.semanticHighlighting.enabled": false
    }
}

[zgoda]

Disabling semantic highlighting has no effect on this, although colours now look acceptable.

[erictraut]

Semantic highlighting should have no impact on diagnostics or vice versa.

I'm trying to replicate your first (simplest) example, and I'm not seeing the same behavior. Let's see if we can determine what's different between your confirmation and mine.

If you click on "fixture" and press F12 (go to definition), where does it take you? For me, it takes me to "site-packages/_pytest/fixtures.py", which looks like this:

I'm trying to determine what declaration of fixture you're using because it appears that your declaration doesn't have a autouse parameter defined.

[zgoda]

~/.local/lib/python3.8/site-packages/_pytest/fixtures.py and this is wrong, this is conda env so this should be like ~/miniconda3/envs/envname/lib/python3.8/site-packages/_pytest/fixtures.py

[jakebailey]

The key thing here is that it says "undefined variable" which is a use-time diagnostic. Naming a parameter in a function call / decorator should not be triggering that diagnostic, as that name is not a use, regardless of if it doesn't actually exist in the function decl.

[zgoda]

This is somehow related to semantic highlighting setting. If I disable it then the issue disappears and reappears once I enable it. Works for both user and workspace settings.

[zgoda]

The tooltip on issue marker in the editor also shows wrong signature for autouse: Any (should be: bool).

[jakebailey]

This might be another bug in the analysis in the background thread that does the semantic tokens (where some diagnostic isn't being thrown away when fetching the type for each symbol); we saw a similar issue during development that was fixed. That's why I bought it up.

RE: the Any, hovering over a named parameter looks at the function declaration for the type, not what you pass in, so it's going to the decorator, not finding autouse, and then saying it's Any (as in "I don't know").

[EonYang]

I got the same issue after updating to 2020.9.0.

Screenshots:

⇡ The error message

⇡ Note that Pylance is able to pull out the function signature which clearly includes the undefined argument

⇡ It's even able to give suggestions.

Downgrade to 2020.8.3 solved my issue.

[erictraut]

I found the cause of this problem. The new semantic token provider was calling the core type evaluator on a parse node that was not an expression. In particular, it was passing the node within a call expression that corresponds to the name of a named parameter — for example, autouse in the example above. I discovered that the hover provider was also contained the same bug, and there might be others as well. Rather than try to find and fix all of the cases where this is occurring, I made the type evaluator more robust so it detects this case and handles it appropriately.

Here is the commit within the pyright repo: https://github.com/microsoft/pyright/commit/d538318a0152785d8585f0f58d74a7c8b02e8742

@judej, this bug is apparently affecting many Pylance users, so we might want to do an interim release of Pylance that cherry-picks this commit from pyright.

[huguesv]

This issue has been fixed in version 2020.9.4, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#202094-10-september-2020