cargo can silently fix some bad lockfiles (use --locked to disable)
Lock files often get corrupted by git merge. This makes all cargo commands silently fix that kind of corruption.
If you want to be sure that your CI does not change the lock file you have commited
---
Then make sure to use `--locked` in your CI
Edit: original description below
---------------
This is a continuation of @dwijnand work in #5809, and closes#5684
This adds a `ignore_errors` arg to reading a lock file which ignores sections it doesn't understand. Specifically things that depend on versions that don't exist in the lock file. Then all users pass false except for the two that relate to `update` command.
I think the open questions for this pr relate to testing.
- Now that we are passing false in all other commands, do they each need a test for a bad lockfile?
- Do we need a test with a more subtly corrupted lock file, or is this always sufficient for `update` to clean up?
Add edition info into metadata
Since edition feature was introduced, external tools have to support this new feature.
But cargo metadata doesn't provide info about package edition.
This commit adds edition field to `SerializedPackage` struct to add the corresponding field into metadata output.
fix: Iteratively apply suggestions from the compiler
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
Hint correct name of profile.debug
Cargo talks about "debug" and "release" builds, but there are "dev" and "release" profiles. [This is a gotcha](https://users.rust-lang.org/t/rust-emscripten-emterpreter/19215/5). I've added an explicit hint that `profile.debug` is supposed to be `profile.dev`.
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
Resolve some Clippy warnings
I'm not sure how these popped up since my PR 8 days ago.
My current hypotheses:
* changes in latest nightly rust/clippy
* new or changed cargo code
* I missed these as I was only touching `src/bin/cargo/main.rs`
For future reference I now iterate with:
touch src/bin/cargo/main.rs src/cargo/lib.rs && cargo +nightly clippy
Since edition feature was introduced, external tools have to support this new feature.
But cargo metadata doesn't provide info about package edition.
This commit adds edition field to SerializedPackage struct
to add the corresponding field into metadata output.
Add more diagnostics to smooth edition transition
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
Use listed dependency name for feature names
This commit updates the implementation of renamed dependencies to use the listed
name of a dependency in Cargo.toml for the name of the associated feature,
rather than using the package name. This'll allow disambiguating between
different packages of the same name and was the intention all along!
Closes#5753
Edition key should be per-target, not per-package
Fixes#5661
I've pushed this WIP PR as I'd love some early feedback on it and some tips on:
* how to best to make it fail if edition is set on a target, but the feature isn't set; and
* what tests this should include (i.e how exhaustive should I go)
Thanks!
This commit updates the implementation of renamed dependencies to use the listed
name of a dependency in Cargo.toml for the name of the associated feature,
rather than using the package name. This'll allow disambiguating between
different packages of the same name and was the intention all along!
Closes#5753
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.
now that we respect gitignore tests can be simplified
There are a lot of test that used a tempfile to avoid the fact that cargo would not init a git in the test folder. (or because they were copy/pasted from one that did.) Now that #5733 landed we can remove them all.
Fix `test --doc` with incompatible lib types.
When I recently changed the doctest handling, I forgot to check the lib type in
the `test --doc` scenario.
I also added the package name to a nearby error message, since it can be
confusing in a workspace setting.
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.
When I recently changed the doctest handling, I forgot to check the lib type in
the `test --doc` scenario.
I also added the package name to a nearby error message, since it can be
confusing in a workspace setting.
Update replaced registry before search
Close#5550.
It seems that updating the replaced registry before search has not been well considered in cargo and I have to add a function to trait `core::source::Source` to get the replaced `SourceId`.
I am not sure whether this is a good design, any advice is welcome.
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.
