-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Categorise fixes
as safe
or maybe_incorrect
#4184
Comments
@MichaReiser I was going through the codebase and it seems all of the code has been migrated, is there something that I am missing with this migration. |
You can search for usages of |
#5119 depends on all
An up-to-date list can be found in the description for #5119. |
## Summary Fixes some of #4184
## Summary Fixes some of #4184
## Summary Fixes some of #4184
## Summary Fixes some of #4184
## Summary Fixes some of #4184.
## Summary Fixes some of #4184.
## Summary Fixes some of #4184.
@charliermarsh I believe there are two more linters that need to be completed - pycodestyle and flake8_pytest_style. May want to reopen until those are done, though I plan on completing them by the end of the weekend. |
Oh sorry, did this get closed accidentally by a PR? Anyway, reopened! |
I think this is done now! @evanrittenhouse let me know if that's wrong — thanks for taking all those on! |
Yup! On to the fun part ;) |
Wohoo. Nice work @evanrittenhouse. |
Part of #4181 and depends on #4183
#4183 introduced the new
Fix::safe
andFix::maybe_incorrect
constructors. The goal of this task is to go through all usages ofFix::unspecified
,Fix::unspecified_edits
,Diagnostic::try_set_from_edit
, andDiagnostic::set_from_edit
and replace them withFix::safe*
orFix::maybe_incorrect
depending on whether the fix is safe or unsafe (may introduce semantic changes).I recommend creating individual PRs per rule because it makes discussing the safety properties of individual fixes easier.
The text was updated successfully, but these errors were encountered: