Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reportUndefinedVariable is a sub category of reportGeneralTypingIssues. #3229

Closed
Gobot1234 opened this issue Mar 20, 2022 · 5 comments
Closed
Labels
as designed Not a bug, working as intended

Comments

@Gobot1234
Copy link

Describe the bug
After updating some of my code with unsafe casts to the type checker with the new support for # type: ignore comments on a per-line basis #3143, I noticed that on lines with NameErrors reportGeneralTypingIssues was supressing any NameErrors I had on the line.

To Reproduce

NameErrorPlease
NameErrorPlease  # type: ignore
NameErrorPlease  # type: ignore[reportGeneralTypingIssues]
NameErrorPlease  # type: ignore[reportUndefinedVariable]
$ pyright test.py        
No configuration file found.
pyproject.toml file found at /Users/James/PycharmProjects/steam.py.
Loading pyproject.toml file at /Users/James/PycharmProjects/steam.py/pyproject.toml
Assuming Python version 3.10
Assuming Python platform Darwin
Auto-excluding **/node_modules
Auto-excluding **/__pycache__
Auto-excluding **/.*
venvPath not specified, so venv settings will be ignored.
stubPath /Users/James/PycharmProjects/steam.py/typings is not a valid directory.
Searching for source files
Found 1 source file
/Users/James/PycharmProjects/steam.py/test.py
  /Users/James/PycharmProjects/steam.py/test.py:1:1 - error: "NameErrorPlease" is not defined (reportUndefinedVariable)
1 error, 0 warnings, 0 informations 
Completed in 2.92sec

Expected behavior
The first # type: ignore comment should supress the NameError, the second should not and the third should.

VS Code extension or command-line
pyright --version
pyright 1.1.231

@erictraut
Copy link
Collaborator

Yes, this is correct. The # type: ignore is defined by PEP 484 and doesn't honor any rule-specific overrides. You can add anything after the # type: ignore comment, but pyright will ignore it.

If you want to suppress particular (pyright-specific) diagnostic rules, you need to use # pyright: ignore[rule-name].

@erictraut erictraut added the as designed Not a bug, working as intended label Mar 20, 2022
@Gobot1234
Copy link
Author

My issue is only about the specific rule codes/names, I'd like it to still notify me there is a NameError (reportUndefinedVariable) even if I add reportGeneralTypingIssues as the ignore code, the two don't seem related, NameErrors aren't, in my opinion at least, typing errors.

@erictraut
Copy link
Collaborator

erictraut commented Mar 20, 2022

The check for an undefined variable is reported as part of the reportUndefinedVariable rule. This is the intended behavior.

We have on occasion separated out some checks into their own diagnostic rule, but we do this only if there's a strong justification — accompanied by feedback from many users. I don't think there's a good justification for this one. We might reconsider in the future if we get sufficient feedback from other users.

@erictraut
Copy link
Collaborator

erictraut commented Mar 20, 2022

If you want to ignore only reportGeneralTypingIssues on that line, you can use:
# pyright: ignore[reportGeneralTypingIssues]. In your code sample above, you are incorrectly using # type: ignore[reportGeneralTypingIssues], which does not support per-rule filtering. So # type: ignore[reportGeneralTypingIssues] is the same as # type: ignore, which suppresses all diagnostics on that line.

@Gobot1234
Copy link
Author

If you want to ignore only reportGeneralTypingIssues on that line, you can use: # pyright: ignore[reportGeneralTypingIssues]. In your code sample above, you are incorrectly using # type: ignore[reportGeneralTypingIssues], which does not support per-rule filtering. So # type: ignore[reportGeneralTypingIssues] is the same as # type: ignore, which suppresses all diagnostics on that line.

Ah right, that makes sense, I see there isn't much you can do short of adding a lot more error codes which is fair enough if you don't want to add them, thank you.

debonte pushed a commit to debonte/pyright that referenced this issue Mar 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
as designed Not a bug, working as intended
Projects
None yet
Development

No branches or pull requests

2 participants