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

D100 with —add-noqa breaks shebang lines #14442

Open
pjspereira opened this issue Nov 18, 2024 · 3 comments
Open

D100 with —add-noqa breaks shebang lines #14442

pjspereira opened this issue Nov 18, 2024 · 3 comments
Labels
bug Something isn't working help wanted Contributions especially welcome

Comments

@pjspereira
Copy link

The —add-noqa breaks shebang lines with the D100 rule on files with no module documentation. Can the shebang line be ignored and the D100 error be assigned to the second line, if it exists?

Example output from ruff check --add-noqa --select D100 --isolated .:

#!/usr/bin/env python  # noqa: D100

import sys

if __name__==__main__’:
    print(sys.argv)

If this script is marked executable, the noqa comment will be passed as a filename to python, which will crash the interpreter, since the file does not exist.

Keywords: shebang D100
Ruff version: 0.6.4

@MichaReiser
Copy link
Member

That sounds reasonable. We need to change the diagnostic location to after the first line

@MichaReiser MichaReiser added bug Something isn't working help wanted Contributions especially welcome labels Nov 18, 2024
@InSyncWithFoo
Copy link
Contributor

CPY001, INP001 and other file-level rules seem to suffer from the same problem.

As a FYI, changing the location would be a breaking change for RyeCharm, which currently uses the value of the range to determine whether it should show an editor-level notice banner. Updating this logic is simple enough, though.

@MichaReiser
Copy link
Member

Yeah, it's certainly not ideal and thanks for the heads up for the RyeCharm integration.

We could consider detecting this in the fix loop but my worry is that it won't be possible to determine if the edit should be applied before or after the shebang line (e.g. what if an edit changes the shebang line). But maybe we can? By only applying said logic if its an insertion at offset 0 and a shebang line is present?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Contributions especially welcome
Projects
None yet
Development

No branches or pull requests

3 participants