-
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
Migrate rustfix to the cargo repo #13005
Conversation
- rustfix stays as the library crate - cargo-fix becomes the new binary crate
…-crates Split rustfix into two crates
This commit starts rewritign the `cargo fix` command in line with the recent discussions around the edition. The main changes here are: * The interactivity of `cargo fix` is removed * Executing `cargo fix` is now a thin veneer over `cargo check` * Fixes are automatically applied when it looks very likely to succeed if we apply them. * Fixes are only applied to the local workspace rather than upstream crates as well. There's still a number of missing features to fill out marked with a few TODO here and there but the test suite is already looking relatively solid. I think we've got a long way to go here but this is hopefully a good start in the direction of where we want to go.
Rewrite the `cargo fix` command
Add AppVeyor configuration
Use a more clever way to replace parts of a file
Make sure that we always run the version that we're compiling locally
Fix tests if `cargo fix` is already installed
Don't use a compilation error to test rustfix but instead use a lint.
This commit causes rustfix to bail out of attempting to fix a crate if it encounters already broken code. We wouldn't want to make the situation worse by accidentally introducing more breakage!
While this shouldn't show up it's best if we don't break users' code. Back out all file changes if this happens and make sure that we never break code with the fixes that we applied.
Override any `deny(warnings)` settings to try to fix as many issues as possible.
This way we can fix fixable warnings with `#[deny(warnings)]` but any unfixed warnings still get printed later as warnings.
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.
Not blockers just call them out.
- Do we want a
A-rustfix
label or just accommendate them inCommand-fix
? - We would like to update
[autolabel]
intriagebot.toml
as well. - Update places mentioning
rusfix
in Cargo Contributor Guide
This command is failing
Seems like there is already a report in The scenario is a newly added package missing in the baseline version. |
We might want to exclude diff --git a/crates/xtask-bump-check/src/xtask.rs b/crates/xtask-bump-check/src/xtask.rs
index cba420f051b..932d3ad1946 100644
--- a/crates/xtask-bump-check/src/xtask.rs
+++ b/crates/xtask-bump-check/src/xtask.rs
@@ -166,6 +166,7 @@ fn bump_check(args: &clap::ArgMatches, config: &cargo::util::Config) -> CargoRes
let mut cmd = ProcessBuilder::new("cargo");
cmd.arg("semver-checks")
.arg("--workspace")
+ .args(&["--exclude", "rustfix"])
.arg("--baseline-rev")
.arg(referenced_commit.id().to_string());
config.shell().status("Running", &cmd)?; |
Thanks for catching all the things I missed!
I think for now I would prefer to just keep one label (
Added.
Updated.
I have applied your patch. |
Thank you ehuss for the migration! @bors r+ |
☀️ Test successful - checks-actions |
Update cargo 7 commits in 71cd3a926f0cf41eeaf9f2a7f2194b2aff85b0f6..9b13310ca596020a737aaa47daa4ed9ff8898a2f 2023-11-20 15:30:57 +0000 to 2023-11-24 16:20:51 +0000 - feat: Add `CARGO_RUSTC_CURRENT_DIR` (unstable) (rust-lang/cargo#12996) - Exited with hard error when custom build file no existence or not in package (rust-lang/cargo#12995) - try running on windows (rust-lang/cargo#13042) - refactor(toml): Better abstract inheritance details (rust-lang/cargo#13021) - cargo-test-support: Add features to the default Cargo.toml file (rust-lang/cargo#12997) - Migrate rustfix to the cargo repo (rust-lang/cargo#13005) - typo: rusc -> rustc (rust-lang/cargo#13019) --- This also removes the check to ensure that `rustfix` between * src/tools/cargo * src/tools/compiletest has the same version, since `rust-lang/rustfix` has migrated to under `rust-lang/cargo`. r? ghost
Update cargo 7 commits in 71cd3a926f0cf41eeaf9f2a7f2194b2aff85b0f6..9b13310ca596020a737aaa47daa4ed9ff8898a2f 2023-11-20 15:30:57 +0000 to 2023-11-24 16:20:51 +0000 - feat: Add `CARGO_RUSTC_CURRENT_DIR` (unstable) (rust-lang/cargo#12996) - Exited with hard error when custom build file no existence or not in package (rust-lang/cargo#12995) - try running on windows (rust-lang/cargo#13042) - refactor(toml): Better abstract inheritance details (rust-lang/cargo#13021) - cargo-test-support: Add features to the default Cargo.toml file (rust-lang/cargo#12997) - Migrate rustfix to the cargo repo (rust-lang/cargo#13005) - typo: rusc -> rustc (rust-lang/cargo#13019) --- This also removes the check to ensure that `rustfix` between * src/tools/cargo * src/tools/compiletest has the same version, since `rust-lang/rustfix` has migrated to under `rust-lang/cargo`. r? ghost
docs: publish nightly doc for `rustfix` `rustfix `has migrated into rust-lang/cargo in <rust-lang/cargo#13005>. We now can publish nightly doc for it.
docs: publish nightly doc for `rustfix` `rustfix `has migrated into rust-lang/cargo in <rust-lang/cargo#13005>. We now can publish nightly doc for it.
docs: publish nightly doc for `rustfix` `rustfix `has migrated into rust-lang/cargo in <rust-lang/cargo#13005>. We now can publish nightly doc for it.
docs: publish nightly doc for `rustfix` `rustfix `has migrated into rust-lang/cargo in <rust-lang/cargo#13005>. We now can publish nightly doc for it.
This migrates the
rustfix
crate from https://github.com/rust-lang/rustfix/ to the cargo repo. The cargo team has been responsible for the client-side ofcargo fix
, and it can make it easier to maintain with all our tooling and tracking here. This crate is used by some external parties (like the compiler), so it will need to be maintained like an "ecosystem" package, but hopefully there shouldn't be any outside requirements (I haven't seen any in several years).After merging, I'll follow up with some things to address in the future, such as:
#[ignore]
annotations, fixing testing on windows, maybe migrating the test code to use different dependencies, various code cleanup.