-
Notifications
You must be signed in to change notification settings - Fork 993
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
Split add_noqa
process into distinctive edit generation and edit application stages
#11265
Conversation
|
Would you mind running some hyperfine benchmarks on this change. The I wonder if we should do some manual testing. What's your experience @charliermarsh with this kind of change? I won't have time to review this today. I plan to look into it on Monday. |
Is there an LSP PR that I can look at in tandem to understand how the API will be used? |
I think |
@charliermarsh Sure, I can do that 😄 |
I've opened it here. |
Thanks, ultimately it will get this merged faster if we have some test coverage. |
cfb4f18
to
cc45f8c
Compare
I'm holding off on merging this until I investigate the root cause of this issue. |
cc45f8c
to
eebad65
Compare
The root of the related issue in the follow-up PR appears to be caused by noqa mappings not generated/passed through to the edit generation function. I've added a test to show that this does work correctly when the proper |
Summary
--add-noqa
now runs in two stages: first, the linter finds all diagnostics that need noqa comments and generate edits on a per-line basis. Second, these edits are applied, in order, to the document.A public-facing function,
generate_noqa_edits
, has also been introduced, which returns noqa edits generated on a per-diagnostic basis. This will be used byruff server
for noqa comment quick-fixes.Test Plan
Unit tests have been updated.