-
Notifications
You must be signed in to change notification settings - Fork 292
Allow type checkers to ignore specific error codes #2153
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
base: main
Are you sure you want to change the base?
Changes from all commits
f4a919a
6ce8087
5cbcac4
6856262
ffc8e7c
a0bc8ad
614bf60
ca781d2
d37d815
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,11 +1,6 @@ | ||
| conformance_automated = "Fail" | ||
| conformant = "Partial" | ||
| notes = """ | ||
| Treats `# type: ignore[error-code]` as only ignoring errors that match the error code `error-code`. | ||
| """ | ||
| conformance_automated = "Pass" | ||
| errors_diff = """ | ||
| Line 14: Unexpected errors ['directives_type_ignore.py:14:10: error[invalid-assignment] Object of type `Literal[""]` is not assignable to `int`'] | ||
| """ | ||
| output = """ | ||
| directives_type_ignore.py:14:10: error[invalid-assignment] Object of type `Literal[""]` is not assignable to `int` | ||
| directives_type_ignore.py:16:10: error[invalid-assignment] Object of type `Literal[""]` is not assignable to `int` | ||
| """ |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,12 +1,7 @@ | ||
| conformant = "Partial" | ||
| notes = """ | ||
| Does not honor "# type: ignore" comment if comment includes additional text. | ||
| """ | ||
| conformance_automated = "Fail" | ||
| conformance_automated = "Pass" | ||
| errors_diff = """ | ||
| Line 14: Unexpected errors ['directives_type_ignore.py:14: error: Incompatible types in assignment (expression has type "str", variable has type "int") [assignment]'] | ||
| """ | ||
| output = """ | ||
| directives_type_ignore.py:14: error: Incompatible types in assignment (expression has type "str", variable has type "int") [assignment] | ||
| directives_type_ignore.py:14: note: Error code "assignment" not covered by "type: ignore" comment | ||
| directives_type_ignore.py:16: error: Incompatible types in assignment (expression has type "str", variable has type "int") [assignment] | ||
| directives_type_ignore.py:16: note: Error code "assignment" not covered by "type: ignore" comment | ||
| """ |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -73,6 +73,15 @@ other comments and linting markers: | |
|
|
||
| # type: ignore # <comment or other marker> | ||
|
|
||
| The form ``# type: ignore[...]`` may be used to suppress only type errors with a | ||
| given error code, though support for this is optional and may vary by type checker: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about also documenting that multiple error codes can be given (comma-separated), and unrecognized error codes should be ignored, if a type checker supports ignoring errors based on specific error code, as @ilevkivskyi suggested here.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are there any other opinions on this? I'm pretty open to changes here. I personally think that the comma separated form doesn't need to be specified explicitly.
Does this mean that Mypy would need to ignore the error code "undefined"? Currently it adds errors at least when using
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I personally think that the approach outlined by @ilevkivskyi is the right one for multi-type-checker interoperability (much better than requiring totally separate ignore comments for each type checker), and I would be happy to fully specify it. But that would be a specification change that puts pyright and pyrefly out of conformance. If we did that, then I think the fulI behavior, including multiple comma separated codes, should be specified. I guess maybe we need feedback at least from pyrefly here: is the "always blanket ignore" behavior pyrefly's UX preference, or just something that was done to satisfy the previous conformance suite requirements? But I think as long as the specification here is looser, as currently written (to accommodate both the pyright/pyrefly behavior and the mypy/zuban/ty behavior), it's not really important to document the multiple-error-codes handling, since effectively all this spec is now saying is that type checkers can do whatever they want with the information inside the brackets. (Either way, I don't think the spec should _require_that type checkers be silent about unknown codes; it should be OK to warn users about them, as mypy does with I'm happy with the current state of this PR as a first step, at least. |
||
|
|
||
| - Given ``# type: ignore[my_code1]``, a type checker may ignore the error code | ||
| ``my_code1`` and choose to treat this form as equivalent to ``# type: ignore``. | ||
| - Alternatively, given ``# type: ignore[my_code1]`` a type checker may suppress the | ||
| error only if the error cause matches the error code ``my_code1``. | ||
| - A bare ``# type: ignore`` must always suppress all type errors. | ||
|
|
||
| .. _`cast`: | ||
|
|
||
| ``cast()`` | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know I'm editing myself here, but this comment needs another update now that the next line is using a made-up error code that no type checker would ever use: