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

fix: Don't back out changes with --broken-code #6312

Merged
merged 1 commit into from
Nov 14, 2018

Conversation

alexcrichton
Copy link
Member

This commit updates the behavior of cargo fix when the --broken-code
flag is passed to Cargo. Previously Cargo would always back out
automatically applied changes to files whenever the fixed code failed to
compile. Now, with the --broken-code flag, fixed code is left as-is.
This means that if the fixed code can be more easily inspected by
humans to detect bugs and such.

The main use case intended here is that if you're working with a large
code base then lints like the edition idiom lints aren't 100% finished
yet to work as smoothly as cargo fix. The idiom lints are often
useful, however, to transition code to be idiomatic (who would have
guessed!) in the new edition.

To ease the experience of using not-quite-ready lints this flag can be
used to hopefully "fix 90% of lint warnings" and then the remaining
compiler errors can be sifted through manually. The intention is that we
have edition documentation indicating this workflow which also
encourages filing bugs for anything that fails to fix, and hopefully
this new behavior will make it easier for us to narrow down what the
minimal test case is too!

@alexcrichton
Copy link
Member Author

r? @ehuss

@ehuss
Copy link
Contributor

ehuss commented Nov 14, 2018

LGTM. Looks like a CI failure with 1.28 not having the same fix available.

This commit updates the behavior of `cargo fix` when the `--broken-code`
flag is passed to Cargo. Previously Cargo would always back out
automatically applied changes to files whenever the fixed code failed to
compile. Now, with the `--broken-code` flag, fixed code is left as-is.
This means that if the fixed code can be more easily inspected by
humans to detect bugs and such.

The main use case intended here is that if you're working with a large
code base then lints like the edition idiom lints aren't 100% finished
yet to work as smoothly as `cargo fix`. The idiom lints are often
useful, however, to transition code to be idiomatic (who would have
guessed!) in the new edition.

To ease the experience of using not-quite-ready lints this flag can be
used to hopefully "fix 90% of lint warnings" and then the remaining
compiler errors can be sifted through manually. The intention is that we
have edition documentation indicating this workflow which also
encourages filing bugs for anything that fails to fix, and hopefully
this new behavior will make it easier for us to narrow down what the
minimal test case is too!
@alexcrichton
Copy link
Member Author

@bors: r=ehuss

@bors
Copy link
Contributor

bors commented Nov 14, 2018

📌 Commit 08dc6da has been approved by ehuss

@bors
Copy link
Contributor

bors commented Nov 14, 2018

⌛ Testing commit 08dc6da with merge 0da2c99...

bors added a commit that referenced this pull request Nov 14, 2018
fix: Don't back out changes with `--broken-code`

This commit updates the behavior of `cargo fix` when the `--broken-code`
flag is passed to Cargo. Previously Cargo would always back out
automatically applied changes to files whenever the fixed code failed to
compile. Now, with the `--broken-code` flag, fixed code is left as-is.
This means that if the fixed code can be more easily inspected by
humans to detect bugs and such.

The main use case intended here is that if you're working with a large
code base then lints like the edition idiom lints aren't 100% finished
yet to work as smoothly as `cargo fix`. The idiom lints are often
useful, however, to transition code to be idiomatic (who would have
guessed!) in the new edition.

To ease the experience of using not-quite-ready lints this flag can be
used to hopefully "fix 90% of lint warnings" and then the remaining
compiler errors can be sifted through manually. The intention is that we
have edition documentation indicating this workflow which also
encourages filing bugs for anything that fails to fix, and hopefully
this new behavior will make it easier for us to narrow down what the
minimal test case is too!
@bors
Copy link
Contributor

bors commented Nov 14, 2018

☀️ Test successful - status-appveyor, status-travis
Approved by: ehuss
Pushing 0da2c99 to master...

@bors bors merged commit 08dc6da into rust-lang:master Nov 14, 2018
@dwijnand
Copy link
Member

Nice! Seems very useful to have.

bors added a commit that referenced this pull request Nov 14, 2018
[beta] fix: Don't back out changes with `--broken-code`

This is a beta backport of #6312
alexcrichton added a commit to alexcrichton/rust that referenced this pull request Nov 14, 2018
bors added a commit to rust-lang/rust that referenced this pull request Nov 15, 2018
[beta]: Update Cargo submodule

Bring in rust-lang/cargo#6312 to the edition release!

Closes #55954
@alexcrichton alexcrichton deleted the fix-broken branch May 6, 2019 18:12
@ehuss ehuss modified the milestones: 1.32.0, 1.31.0 Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants