This change splits out staged changes from dirty changes, and lets the
user know if they should consider using the --allow-staged flag.
Signed-off-by: Jordan Justen <jljusten@gmail.com>
This, like `--prepare-for`, will be part of the transition guide which
automatically applies the necessary lint group from the compiler to associated
code.
The `--edition-idioms` flag does not take an argument and will automatically
enable the right lint group based on the edition being compiled for.
cc #52679
Rename `--prepare-for` to `--edition`, drop arg
This commit tweaks the UI of `cargo fix` for the edition. Previously you'd
execute `cargo fix --prepare-for 2018`, but that's a lot of typing! Plus it's
some manual data that Cargo can already infer.
Instead, after this commit, you now type `cargo fix --edition`, and that's it!
The idea is that this'll tell Cargo to fix code for the *next* edition,
inferring whatever edition is in use and figuring out what to pass to rustc.
Functionality-wise this should be the exact same as `--prepare-for 2018` though
If others agree w/ this change I'll send a PR to the edition guide after this
merges!
This commit tweaks the UI of `cargo fix` for the edition. Previously you'd
execute `cargo fix --prepare-for 2018`, but that's a lot of typing! Plus it's
some manual data that Cargo can already infer.
Instead, after this commit, you now type `cargo fix --edition`, and that's it!
The idea is that this'll tell Cargo to fix code for the *next* edition,
inferring whatever edition is in use and figuring out what to pass to rustc.
Functionality-wise this should be the exact same as `--prepare-for 2018` though
If others agree w/ this change I'll send a PR to the edition guide after this
merges!
This commit updates the `cargo fix` implementation to iteratively apply fixes
from the compiler instead of only once. Currently the compiler can sometimes
emit overlapping suggestions, such as in the case of transitioning
::foo::<::Bar>();
to ...
crate::foo::<crate::Bar>();
and `rustfix` rightfully can't handle overlapping suggestions as there's no
clear way of how to disambiguate the fixes. To fix this problem Cargo will now
run `rustc` and `rustfix` multiple times, attempting to reach a steady state
where no fixes failed to apply.
Naturally this is a pretty tricky thing to do and we want to be sure that Cargo
doesn't loop forever, for example. A number of safeguards are in place to
prevent Cargo from going off into the weeds when fixing files, notably avoiding
to reattempt fixes if no successful fixes ended up being applied.
Closes#5813Closesrust-lang/rust#52754
This commit adds two diagnostics in particular to ease the transition into the
2018 edition. The current transition process is pretty particular and must be
done carefully, so let's try to automate things to make it as painless as
possible! Notably the new diagnostics are:
* If you `cargo fix --prepare-for 2018` a crate which already has the 2018
edition enabled, then an error is generated. This is because the compiler
can't prepare for the 2018 edition if you're already in the 2018 edition, the
lints won't have a chance to fire. You can only execute `--prepare-for 2018`
over crates in the 2015 edition.
* If you `cargo fix --prepare-for 2018` and have forgotten the
`rust_2018_preview` feature, a warning is issued. The lints don't fire unless
the feature is enabled, so this is intended to warn in this situation to
ensure that lints fire as much as they can.
After this commit if `cargo fix --prepare-for` exits successfully with zero
warnings then crates should be guaranteed to be compatible!
Closes#5778
The previous heuristic for fixing packages was to fix all packages in a
workspace, aka those with path dependencies. Instead this commit switches cargo
over to only fixing the "primary" package, or those requested on the command
line or implicitly via cwd.
This will later help us identify which packages are being targeted so we can
provide tailored warnings and errors for mixed up transition steps.
When running `cargo new`, we check to see if you are inside a git
repository. If you are, we do not initialize a new git repo for
your project unless you specifically asked for it using --vcs.
(See #1210 for more background).
This commit changes that behavior to *also* create a new repo if
the project would be an ignored path in the parent repository.
This way, if your home directory is a git repository, as long as
you have ignored the directory you are creating a new project in,
we will instantiate a git repository without you having to
specifically request it.
Looks like cargo traverses the filesystem & fails if it runs into a
Cargo.toml that doesn't declare a target. I couldn't find a nice way to
re-engineer the test to avoid this issue. So I'll leave that as someone
else's exercise.
* Collapse the nested cargotest::support module into the cargotest
module (merge the mod.rs's)
* Rename the cargotest module to support
* Nest the top-level hamcrest module into support
By rewriting the tests, with rerast (https://github.com/google/rerast),
to use the newly introduced "at" method.
First I added the following temporary function to cargotest::support:
pub fn project_foo() -> ProjectBuilder {
project("foo")
}
Then I defined the following rewrite.rs:
use cargotest::support::{ project, project_foo };
fn rule1(a: &'static str) {
replace!(project("foo") => project_foo());
replace!(project(a) => project_foo().at(a));
}
Then I ran rerast:
cargo +nightly rerast --rules_file=rewrite.rs --force --targets tests --file tests/testsuite/main.rs
Finally I searched and replaced the references to project_foo with
argument-less project (a little awkardly on macOS with a git clean).
find tests -type f -exec sed -i -e 's/project_foo/project/g' {} +
git clean -d tests
This commit imports the `cargo fix` subcommand in rust-lang-nursery/rustfix
directly into Cargo as a subcommand. This should allow us to ease our
distribution story of `cargo fix` as we prepare for the upcoming 2018 edition
release.
It's been attempted here to make the code as idiomatic as possible for Cargo's
own codebase. Additionally all tests from cargo-fix were imported into Cargo's
test suite as well. After this lands and is published in nightly the `cargo-fix`
command in rust-lang-nursery/rustfix will likely be removed.
cc rust-lang/rust#52272
