-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Add transactional semantics to rustfix
#14747
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @weihanglo (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
c34580f
to
c738b3e
Compare
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.
This is awesome! Thank you for this patch!
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.
Looks like the last three commits are mostly refactoring. To make things clearer and more traceable, could we move them to a separate or a follow-up PR?
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.
Yes, certainly. I got a bit over-zealous during the original work, and that's actually why I pulled them out into these separate commits. I'll move those commits out of this PR.
the last three commits
Do you mean last three, or last four? That is, should I remove all except the first commit, or do you want to include the changes to Error
? If the former, I think this PR should still remove the MaybeAlreadyReplaced
variant, as discussed in a different comment.
As for submitting those commits as potential refactors, I was thinking I'd open an issue for them first, since in retrospect, they could use some discussion. But also, I don't want to increase your workload unnecessarily, so no worries if the additional commits aren't really something the project is looking to review/adopt at this time.
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.
Yeah. IMO ideally this PR could be splitted into three maybe?
- transactional semantics (fixes [rustfix] Two suggestions applying to the same span cause syntax errors #14699)
AlreadyReplaced
handling (fixescargo fix
: duplicate diagnostic detection does not handle insert-only replacements #13027)- Other refactors/optimizations
I don't think we need extra issues for any of them.
@weihanglo Thank you so much for your review! I'll reply soon to your comments and submit some updates, but I won't be able to complete the changes until tomorrow at the earliest. |
c738b3e
to
957d713
Compare
@saites |
Yes, I think I can handle that. |
957d713
to
f73b1d8
Compare
Thank you for working on this! I just did a real world test: @bors r+ |
Feel free to work on refactoring pull requests! |
☀️ Test successful - checks-actions |
rustfix: replace special-case duplicate handling with error ### What does this PR try to resolve? This PR changes how conflicts are handled in `rustfix`. By design, `cargo fix` repeatedly compiles the code, collects suggested changes, and applies changes that don't conflict with one another. Often, conflicts arise because the same suggestion is reported multiple times e.g., due to a macro expansion. There have been previous changes to address that specific case, but following [the PR to add transactional semantics](#14747), it makes sense to change how this is handled. Specifically, this PR adds details to `Error::AlreadyReplaced` to indicate whether the specific replacement is identical to the one it conflicts with, allowing callers to handle this case, rather than special-casing it within `replace.rs` itself. To that point, this PR changes `fix.rs` and `lib.rs` to handle identical replacements by skipping the conflicting suggestion. This is not exactly identical to their previous behavior: before, it skipped a suggestion if any _solution_ had been applied, whereas this skips it if any _replacement within a solution_ has been applied. While more expansive, this is very much the spirit of the goal described above. ### How should we test and review this PR? The existing tests have been updated to account for this change. ### Additional information See: #13027
Update cargo 16 commits in 0310497822a7a673a330a5dd068b7aaa579a265e..4a2d8dc636445b276288543882e076f254b3ae95 2024-11-01 19:27:56 +0000 to 2024-11-09 19:10:33 +0000 - test: adjust `cargo_test_env` to unblock rust submodule update (rust-lang/cargo#14803) - feat(warnings): add build.warnings option (rust-lang/cargo#14388) - Revert "feat: Add `CARGO_RUSTC_CURRENT_DIR`" (rust-lang/cargo#14799) - CI: make the `lint-docs` job required (rust-lang/cargo#14797) - Switch CI from bors to merge queue (rust-lang/cargo#14718) - docs(test): Document Execs assertions based on port effort (rust-lang/cargo#14793) - fix(test): Make redactions consistent with snapbox (rust-lang/cargo#14790) - test(gc): Update remaining unordered tests to snapbox (rust-lang/cargo#14785) - Normalize the `target` paths (rust-lang/cargo#14497) - rustfix: replace special-case duplicate handling with error (rust-lang/cargo#14782) - test: Update some emaining unordered tests to snapbox (rust-lang/cargo#14781) - Change config paths to only check CARGO_HOME for cargo-script (rust-lang/cargo#14749) - Enable transfer feature in triagebot (rust-lang/cargo#14777) - Add transactional semantics to `rustfix` (rust-lang/cargo#14747) - doc: fix `GlobalContext` reference (rust-lang/cargo#14773) - chore: update handlebars to v6, fix build error (rust-lang/cargo#14772)
Update cargo 16 commits in 0310497822a7a673a330a5dd068b7aaa579a265e..4a2d8dc636445b276288543882e076f254b3ae95 2024-11-01 19:27:56 +0000 to 2024-11-09 19:10:33 +0000 - test: adjust `cargo_test_env` to unblock rust submodule update (rust-lang/cargo#14803) - feat(warnings): add build.warnings option (rust-lang/cargo#14388) - Revert "feat: Add `CARGO_RUSTC_CURRENT_DIR`" (rust-lang/cargo#14799) - CI: make the `lint-docs` job required (rust-lang/cargo#14797) - Switch CI from bors to merge queue (rust-lang/cargo#14718) - docs(test): Document Execs assertions based on port effort (rust-lang/cargo#14793) - fix(test): Make redactions consistent with snapbox (rust-lang/cargo#14790) - test(gc): Update remaining unordered tests to snapbox (rust-lang/cargo#14785) - Normalize the `target` paths (rust-lang/cargo#14497) - rustfix: replace special-case duplicate handling with error (rust-lang/cargo#14782) - test: Update some emaining unordered tests to snapbox (rust-lang/cargo#14781) - Change config paths to only check CARGO_HOME for cargo-script (rust-lang/cargo#14749) - Enable transfer feature in triagebot (rust-lang/cargo#14777) - Add transactional semantics to `rustfix` (rust-lang/cargo#14747) - doc: fix `GlobalContext` reference (rust-lang/cargo#14773) - chore: update handlebars to v6, fix build error (rust-lang/cargo#14772)
What does this PR try to resolve?
This PR adds transactional semantics to
rustfix::Data
, enablingrustfix::CodeFix
to applySuggestion
s as atomic units and rollback partially-applied changes when they conflict with existing ones. The basic approach and goals are discussed in a comment on issue 14699. In that comment, I proposed a solution which extended the existingState
enumeration, but described an alternative that simplifies the overall tracking of incoming changes; this PR implements the latter.How should we test and review this PR?
I've added an additional test and updated the existing ones. The tests in
parse_and_replace
already cover this case, particularly thanks to #14765 added by @weihanglo. It's still a good idea to experiment withcargo clippy --fix
on repos that match the cases described in these open issues.Additional information
Fixes #14699
Fixes rust-lang/rust-clippy/issues/13549