-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Warn on invalid # noqa
rule codes
#12811
base: main
Are you sure you want to change the base?
Conversation
# noqa
rule codes
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.
It's not "breaking", but I'd suggest we ship it in a minor.
Seems reasonable to me.
I think it might be useful for #12831 to be fixed as well.
There's now a |
@charliermarsh do you plan on merging this for the 0.6 release? |
@MichaReiser - No, I should address Dhruv’s concern first but don’t have time immediately. |
5894aa0
to
c2e9746
Compare
On `main` we warn the user if there is an invalid noqa comment[^1] and at least one of the following holds: - There is at least one diagnostic - A lint rule related to `noqa`s is enabled (e.g. `RUF100`) This is probably strange behavior from the point of view of the user, so we now show invalid `noqa`s even when there are no diagnostics. Closes #12831 [^1]: For the current definition of "invalid noqa comment", which may be expanded in #12811 . This PR is independent of loc. cit. in the sense that the CLI warnings should be consistent, regardless of which `noqa` comments are considered invalid.
Summary
Today, we already warn if you do
# ruff: noqa: F401F841
... But not inline (e.g.,import os # noqa: F401F841
).This PR extends the warnings to the latter case.
It's not "breaking", but I'd suggest we ship it in a minor.
Fixes #15682