* Docscrape unit not having dev-dependencies included
* Sources for reverse-dependencies generated to the wrong directory
* Incorrect features being selected for Docscrape units
* Panics from Docscrape-dependent packages not being available
Make future-incompat-report output more user-friendly
When the user enables `--future-incompat-report`, we now display
a high-level summary of the problem, as well as several suggestions
for fixing the affected crates.
The command `cargo report future-incompatibilities` now takes
a `--crate` option, which can be used to display a report
(including the actual lint messages) for a single crate.
When this option is not used, we display the report for all
crates.
Sample output from the `actix` crate:
`> RUSTFLAGS="-Z future-incompat-test" ~/repos/cargo/target/debug/cargo build -Z future-incompat-report
`
```
Finished dev [unoptimized + debuginfo] target(s) in 2.09s
warning: the following packages contain code that will be rejected by a future version of Rust: actix v0.11.1 (/home/aaron/repos/actix/actix), ahash v0.7.4, arc-swap v0.4.4, autocfg v1.0.0, crossbeam-utils v0.8.5, futures-macro v0.3.17, futures-util v0.3.17, lazy_static v1.4.0, libc v0.2.103, lock_api v0.4.5, log v0.4.8, mio v0.7.13, parking_lot_core v0.8.5, signal-hook-registry v1.2.0, smallvec v1.7.0, syn v1.0.77, tokio v1.12.0, tokio-util v0.6.8, unicode-xid v0.2.0, version_check v0.9.3
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 2`
```
`> RUSTFLAGS="-Z future-incompat-test" ~/repos/cargo/target/debug/cargo build -Z future-incompat-report --future-incompat-report -Z unstable-options`
```
Finished dev [unoptimized + debuginfo] target(s) in 2.12s
warning: the following packages contain code that will be rejected by a future version of Rust: actix v0.11.1 (/home/aaron/repos/actix/actix), ahash v0.7.4, arc-swap v0.4.4, autocfg v1.0.0, crossbeam-utils v0.8.5, futures-macro v0.3.17, futures-util v0.3.17, lazy_static v1.4.0, libc v0.2.103, lock_api v0.4.5, log v0.4.8, mio v0.7.13, parking_lot_core v0.8.5, signal-hook-registry v1.2.0, smallvec v1.7.0, syn v1.0.77, tokio v1.12.0, tokio-util v0.6.8, unicode-xid v0.2.0, version_check v0.9.3
note:
To solve this problem, you can try the following approaches:
- Some affected dependencies have newer versions available.
You may want to consider updating them to a newer version to see if the issue has been fixed.
ahash v0.7.4 has the following newer versions available: 0.7.5
arc-swap v0.4.4 has the following newer versions available: 0.4.8, 1.1.0, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.4.0
autocfg v1.0.0 has the following newer versions available: 1.0.1
log v0.4.8 has the following newer versions available: 0.4.11, 0.4.13, 0.4.14
signal-hook-registry v1.2.0 has the following newer versions available: 1.2.1, 1.2.2, 1.3.0, 1.4.0
syn v1.0.77 has the following newer versions available: 1.0.78, 1.0.79, 1.0.80
unicode-xid v0.2.0 has the following newer versions available: 0.2.1, 0.2.2
- If the issue is not solved by updating the dependencies, a fix has to be
implemented by those dependencies. You can help with that by notifying the
maintainers of this problem (e.g. by creating a bug report) or by proposing a
fix to the maintainers (e.g. by creating a pull request):
- actix:0.11.1
- Repository: https://github.com/actix/actix
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "actix:0.11.1"
- ahash:0.7.4
- Repository: https://github.com/tkaitchuck/ahash
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "ahash:0.7.4"
- arc-swap:0.4.4
- Repository: https://github.com/vorner/arc-swap
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "arc-swap:0.4.4"
- autocfg:1.0.0
- Repository: https://github.com/cuviper/autocfg
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "autocfg:1.0.0"
- crossbeam-utils:0.8.5
- Repository: https://github.com/crossbeam-rs/crossbeam
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "crossbeam-utils:0.8.5"
- futures-macro:0.3.17
- Repository: https://github.com/rust-lang/futures-rs
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "futures-macro:0.3.17"
- futures-util:0.3.17
- Repository: https://github.com/rust-lang/futures-rs
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "futures-util:0.3.17"
- lazy_static:1.4.0
- Repository: https://github.com/rust-lang-nursery/lazy-static.rs
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "lazy_static:1.4.0"
- libc:0.2.103
- Repository: https://github.com/rust-lang/libc
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "libc:0.2.103"
- lock_api:0.4.5
- Repository: https://github.com/Amanieu/parking_lot
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "lock_api:0.4.5"
- log:0.4.8
- Repository: https://github.com/rust-lang/log
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "log:0.4.8"
- mio:0.7.13
- Repository: https://github.com/tokio-rs/mio
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "mio:0.7.13"
- parking_lot_core:0.8.5
- Repository: https://github.com/Amanieu/parking_lot
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "parking_lot_core:0.8.5"
- signal-hook-registry:1.2.0
- Repository: https://github.com/vorner/signal-hook
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "signal-hook-registry:1.2.0"
- smallvec:1.7.0
- Repository: https://github.com/servo/rust-smallvec
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "smallvec:1.7.0"
- syn:1.0.77
- Repository: https://github.com/dtolnay/syn
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "syn:1.0.77"
- tokio:1.12.0
- Repository: https://github.com/tokio-rs/tokio
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "tokio:1.12.0"
- tokio-util:0.6.8
- Repository: https://github.com/tokio-rs/tokio
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "tokio-util:0.6.8"
- unicode-xid:0.2.0
- Repository: https://github.com/unicode-rs/unicode-xid
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "unicode-xid:0.2.0"
- version_check:0.9.3
- Repository: https://github.com/SergioBenitez/version_check
- Detailed warning command: `cargo report future-incompatibilities --id 3 --crate "version_check:0.9.3"
- If waiting for an upstream fix is not an option, you can use the `[patch]`
section in `Cargo.toml` to use your own version of the dependency. For more
information, see:
https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section
note: this report can be shown with `cargo report future-incompatibilities -Z future-incompat-report --id 3`
```
`> RUSTFLAGS="-Z future-incompat-test" ~/repos/cargo/target/debug/cargo report future-incompatibilities -Z future-incompat-report --color never | head -n 100`
```
The following warnings were discovered during the build. These warnings are an
indication that the packages contain code that will become an error in a
future release of Rust. These warnings typically cover changes to close
soundness problems, unintended or undocumented behavior, or critical problems
that cannot be fixed in a backwards-compatible fashion, and are not expected
to be in wide use.
Each warning should contain a link for more information on what the warning
means and how to resolve it.
- Some affected dependencies have newer versions available.
You may want to consider updating them to a newer version to see if the issue has been fixed.
ahash v0.7.4 has the following newer versions available: 0.7.5
arc-swap v0.4.4 has the following newer versions available: 0.4.8, 1.1.0, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.4.0
autocfg v1.0.0 has the following newer versions available: 1.0.1
log v0.4.8 has the following newer versions available: 0.4.11, 0.4.13, 0.4.14
signal-hook-registry v1.2.0 has the following newer versions available: 1.2.1, 1.2.2, 1.3.0, 1.4.0
syn v1.0.77 has the following newer versions available: 1.0.78, 1.0.79, 1.0.80
unicode-xid v0.2.0 has the following newer versions available: 0.2.1, 0.2.2
The package `actix v0.11.1 (/home/aaron/repos/actix/actix)` currently triggers the following future incompatibility lints:
> warning: use of deprecated struct `utils::Condition`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:25:9
> |
> 25 | impl<T> Condition<T>
> | ^^^^^^^^^
> |
> note: the lint level is defined here
> --> actix/src/lib.rs:30:10
> |
> 30 | #![allow(deprecated)]
> | ^^^^^^^^^^
>
> warning: use of deprecated struct `utils::Condition`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:42:21
> |
> 42 | impl<T> Default for Condition<T>
> | ^^^^^^^^^
>
> warning: use of deprecated struct `utils::Condition`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:47:9
> |
> 47 | Condition {
> | ^^^^^^^^^
>
> warning: use of deprecated struct `utils::Condition`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/lib.rs:120:28
> |
> 120 | pub use crate::utils::{Condition, IntervalFunc, TimerFunc};
> | ^^^^^^^^^
>
> warning: use of deprecated associated function `std::sync::atomic::AtomicUsize::compare_and_swap`: Use `compare_exchange` or `compare_exchange_weak` instead
> --> actix/src/address/channel.rs:512:49
> |
> 512 | let actual = self.inner.num_senders.compare_and_swap(curr, next, SeqCst);
> | ^^^^^^^^^^^^^^^^
>
> warning: use of deprecated associated function `std::sync::atomic::AtomicUsize::compare_and_swap`: Use `compare_exchange` or `compare_exchange_weak` instead
> --> actix/src/address/channel.rs:636:49
> |
> 636 | let actual = self.inner.num_senders.compare_and_swap(curr, next, SeqCst);
> | ^^^^^^^^^^^^^^^^
>
> warning: use of deprecated associated function `std::sync::atomic::AtomicUsize::compare_and_swap`: Use `compare_exchange` or `compare_exchange_weak` instead
> --> actix/src/address/channel.rs:697:49
> |
> 697 | let actual = self.inner.num_senders.compare_and_swap(curr, next, SeqCst);
> | ^^^^^^^^^^^^^^^^
>
> warning: use of deprecated field `utils::Condition::waiters`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:31:9
> |
> 31 | self.waiters.push(tx);
> | ^^^^^^^^^^^^
>
> warning: use of deprecated field `utils::Condition::waiters`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:36:23
> |
> 36 | for waiter in self.waiters {
> | ^^^^^^^^^^^^
>
> warning: use of deprecated field `utils::Condition::waiters`: Please use tokio::sync::oneshot::Sender instead.
> --> actix/src/utils.rs:48:13
> |
> 48 | waiters: Vec::new(),
> | ^^^^^^^^^^^^^^^^^^^
>
> warning: unused variable: `ctx`
> --> actix/src/actor.rs:78:27
> |
> 78 | fn started(&mut self, ctx: &mut Self::Context) {}
> | ^^^ help: if this is intentional, prefix it with an underscore: `_ctx`
> |
> note: the lint level is defined here
> --> actix/src/actor.rs:72:9
> |
> 72 | #[allow(unused_variables)]
> | ^^^^^^^^^^^^^^^^
```
When the user enables `--future-incompat-report`, we now display
a high-level summary of the problem, as well as several suggestions
for fixing the affected crates.
The command `cargo report future-incompatibilities` now takes
a `--crate` option, which can be used to display a report
(including the actual lint messages) for a single crate.
When this option is not used, we display the report for all
crates.
Add rust_metadata to SerializedPackage
After the rust_version field was stabilized in #9732 this adds the
rust_version as output to the `cargo metadata` command, so tools like
Clippy can read and use it as well.
We will probably need this for rust-lang/rust-clippy#7765
After the rust_version field was stabilized in #9732 this adds the
rust_version as output to the `cargo metadata` command, so tools like
Clippy can read and use it as well.
Skip all `cargo fix` that tends to write to registry cache.
Skip all `cargo fix` that tends to write to registry cache.
This is a temporary hack for #9857. The real fix may need to touch rustc.
Stabilize named profiles
This stabilizes the named profiles feature. As an overview of what this does, it allows specifying custom named profiles, such as:
```toml
[profile.release-lto]
inherits = "release"
lto = true
```
And enables the use of the `--profile` CLI option to choose a profile by name.
Another key change here is that cargo now only uses a single profile per command. Previously, some commands such as `cargo test` would use a mix of profiles based on which package and target were being built.
### Summary of new behavior
* Profiles can now have arbitrary names. New profiles require the `inherits` key.
* The `--profile` flag is now available on all build commands.
* The `CompileMode` is no longer considered for choosing the profile, only one profile will be used. Previously, building a test, benchmark, or doctest would use the test or bench profile, and all dependencies would use the dev/release profiles. This change is done to arguably make it easier to understand, and to possibly give more desired and intuitive behavior.
* The `test` profile now inherits settings from the `dev` profile (and `bench` from `release`).
### Deviations from the original RFC and implementation
* The original RFC indicated that `--all-targets` without `--profile` would retain the old behavior where it would use different profiles for different targets. However, the implementation uses a single profile, to avoid confusion and to keep things simple.
* The `dir-name` key is not exposed to the user. The implementation is retained to handle mapping of built-in profile names (test/dev→debug, bench→release). This can be exposed in the future if necessary.
### Notes about this PR
* Fixed an issue where the duplicate package override check would randomly return matches for inherited profiles like `test`.
* I left some of the old, vestigial code behind to possibly make it easier to revert this PR if necessary. If this does land, I think it can be eventually removed (code using `Feature::named_profiles` and various things using `named_profiles_enabled`).
* Added `target` to reserved list, just because.
* Adds a warning if `--release` is combined with `--profile` in `cargo rustc`, `check`, or `fix`. The `--release` flag was being ignored.
### Hazards and concerns
* This has had very little real-world testing.
* Custom profile directories may conflict with other things in the `target` directory. We have reserved profile names that currently conflict (such as `doc` or `package`). However, they can still collide with target names. This also presents a hazard if Cargo ever wants to add new things to that top directory. We decided to proceed with this because:
* We currently have no plans to add new built-in profiles.
* We have reserved several profile names (including anything starting with "cargo"), and the profile name syntax is deliberately limited (so cargo is still free to add `.` prefixed hidden directories).
* A user creating a profile that collides with a target name resides in the "don't do that" territory. Also, that shouldn't be catastrophic, as the directories are still somewhat organized differently.
* Artifacts may no longer be shared in some circumstances. This can lead to substantially increased `target` directory sizes (and build times), particularly if the `test` profile is not the same as the `dev` profile. Previously, dependencies would use the `dev` profile for both. If the user wants to retain the old behavior, they can use an override like `[profile.test.package."*"]` and set the same settings as `dev`.
* This may break existing workflows. It is possible, though unlikely, that changes to the profile settings will cause changes to how things build in such a way to break behavior.
* Another example is using something like `cargo build` to prime a cache that is used for `cargo test`, and there is a custom `test` profile, the cache will no longer be primed.
* The legacy behavior with `cargo rustc`, `cargo check`, and `cargo fix` may be confusing. We may in the future consider something like a `--mode` flag to formalize that behavior.
* The `PROFILE` environment variable in build scripts may cause confusion or cause problems since it only sets `release` or `debug`. Some people may be using that to determine if `--release` should be used for a recursive `cargo` invocation. Currently I noted in the documentation that it shouldn't be used. However, I think it could be reasonable to maybe add a separate environment variable (`PROFILE_NAME`?) that exposes the actual profile used. We felt that changing the existing value could cause too much breakage (and the mapping of debug→dev is a little awkward).
Closes#6988
Distinguish lockfile version req from normal dep in resolver error message
Resolves#9840
This PR adds a new variant `OptVersionReq::Locked` as #9840 described.
The new variant represents as a locked version requirement that contains
an exact locked version and the original version requirement.
Previously we use exact version req to synthesize locked version req.
Now we make those need a truly locked to be `OptVersionReq::Locked`,
including:
- `[patch]`: previous used exact version req to emulate locked version,
and it only need to lock dep version but not source ID, so we make
an extra method `Dependency::lock_version` for it.
- Dependencies from lock files: No need to change the call site.
Allow `cargo update --precise` with metadata.
`cargo update --precise` would require that the version matches *exactly*, including build metadata. Usually the build metadata is ignored (like in dependency declarations), but in this circumstance it isn't. This can be awkward in some cases where it can be more convenient to type just the version number without the build metadata.
This changes it so that if the metadata isn't provided, then it will be ignored when matching. Otherwise, it will be honored. This is slightly different from a version requirement like `=1.2.3+foo` which ignores the metadata completely.
This also adds a slightly better error message if you don't type in valid syntax for a version number (previously it would just emit the `no matching package` error).
- `set_require_newline_after_table` was added in #2680 back in 2016
- `set_allow_duplicate_after_longer_table` was added in #6761 in 2019
Several years later, this PR is turning these warnings into errors.
The function and documentation was kept so we can add additional hacks
in the future, like if we switch TOML parsers.
Improve "wrong output" error.
The error message for an improperly formatted build script output was a bit abrupt and unhelpful. This adds some more details to the error message.
The lint now ignores derived `Clone` and `Debug` implementations, as of
PR rust-lang/rust#85200, which landed a couple of days ago.
I sprinkled `#[allow(dead_code)]` in a few places; the fields are not
expected to be read since they are just part of a very specific test.
Enable some tests on windows.
This enables some more tests on windows that were disabled because `echo` is not always available. It's pretty easy to make a custom `echo`, so that's what this does. I'm generally not comfortable with disabling tests just because there is an inconvenience like this.
rev = "refs/pull/𑑛/head"
GitHub exposes a named reference associated with the head of every pull request. For example, you can fetch *this* pull request:
```console
$ git fetch origin refs/pull/9859/head
$ git show FETCH_HEAD
```
Usually when I care about pulling in a patch of one of my dependencies using `[patch.crates-io]`, this is the ref that I want to depend on. None of the alternatives are good:
- `{ git = "the fork", branch = "the-pr-branch" }` — this is second closest to what I want, except that when the PR merges and the PR author deletes their fork, it'll breaks.
- `{ git = "the fork", rev = "commithash" }` — same failure mode as the previous. Also doesn't stay up to date with PR, which is sometimes what I want.
- `{ git = "the upstream", rev = "commithash" }` — doesn't work until the PR is merged or the repo owner creates a named branch or tag containing the PR commit among its ancestors, because otherwise the commit doesn't participate in Cargo's fetch.
- `{ git = "my own fork of PR author's repo", branch = "the-pr-branch" }` — doesn't stay up to date with PR.
This PR adds support for specifying a git dependency on the head of a pull request via the existing `rev` setting of git dependencies: `{ git = "the upstream", rev = "refs/pull/9859/head" }`.
Previously this would fail because the `cargo::sources::fetch` function touched in this pull request did not fetch the refspec that we care about. The failures look like:
```console
error: failed to get `mockall` as a dependency of package `testing v0.0.0`
Caused by:
failed to load source for dependency `mockall`
Caused by:
Unable to update https://github.com/asomers/mockall?rev=refs/pull/330/head
Caused by:
revspec 'refs/pull/330/head' not found; class=Reference (4); code=NotFound (-3)
```
If dual purposing `rev` for this is not appealing, I would alternatively propose `{ git = "the upstream", pull-request = "9859" }` which Cargo will interpret using GitHub's ref naming convention as `refs/pull/9859/head`.
Stabilize patch-in-config (and prefer config over manifest)
Tracking issue: https://github.com/rust-lang/cargo/issues/9269
---
This stabilizes the `patch-in-config` feature ([unstable entry](https://doc.rust-lang.org/cargo/reference/unstable.html#patch-in-config)) following the discussion in https://github.com/rust-lang/cargo/issues/9269#issuecomment-904913263.
As requested, this PR _also_ changes the precedence behavior such that a `[patch]` for the same dependency in both `.cargo/config.toml` and `Cargo.toml` prefers the patch from the configuration file over the one from the manifest, which matches the behavior of other overlapping configuration options. The corresponding test has also been updated to reflect this change in behavior.
Change `cargo fix --edition` to only fix edition lints.
This changes it so that `cargo fix --edition` will only fix edition lints. The reason for this is that sometimes non-edition lints get in the way, and make suggestions that can cause failures. An example is a user that only ever runs `cargo test` or `cargo check --profile=test` locally, and doesn't realize there are problems with running without `cfg(test)` such as unused warnings.
This works by using `--cap-lints=allow` along with `--force-warn` which takes precedence over `cap-lints`.
This only works on nightly since `--force-warn` is still unstable. I will update this as part of #9800.
Closes#5738
Show desc of well known subcommands (fmt, clippy) in cargo --list
Fixes#8680
An approach to #8680 that shows these in `cargo --list` without showing them directly in the `cargo --help`.
```
➜ cargo git:(desc) target/debug/cargo --list | grep clippy
clippy Checks a package to catch common mistakes and improve your Rust code.
```
Here's what mine looks like visually now:
Fix test not to rely on `cargo` in PATH.
This fixes a test that was trying to execute `cargo` from PATH. This test doesn't work on rust-lang/rust where the rustup installation is removed, and thus there is no `cargo` in PATH.
Improve resolver message to include dependency requirements
Resolves#6199.
Thanks for previous efforts: #5452, #6374, #6665, which are great but somehow outdated, so I tweak them and create this PR. This will also be obsolete if we ship pubgrub-rs with cargo in the future 😃 But before that happens, IMO these changes are still helpful.
---
This PR changes the resolver error message from
216f915c46/tests/testsuite/build.rs (L1104-L1106)
to
0afd40b4de/tests/testsuite/build.rs (L1104-L1106)
Also provide different message for different source kinds, such like:
0afd40b4de/tests/testsuite/build.rs (L2810-L2812)
## TODO?
From https://github.com/rust-lang/cargo/pull/5452#issuecomment-402832200, there shall be at least one task left behind:
> 3. Special case pind by a lock file and not a `"=1.1.2"` in a dependency. Also add a "note: try cargo update" to the end.
In this PR, `validate_links` also faces this issue that a dependency requirement is locked into a precise version `=0.1.0`.
a5f8bc94f5/tests/testsuite/build_script.rs (L1002-L1004)
I am uncertain about how to resolve this. Besides the function`validate_links`, is this problem really a thing that may happen? If not, since `validate_links` only handles old validation logic, it may be ok to drop the commit a5f8bc94f5 and leave it as is.
Fix panic with build-std of a proc-macro.
If you try to run `cargo build -Zbuild-std` in a proc-macro project, cargo would panic in [`check_collisions`](835d5576e1/src/cargo/core/compiler/context/mod.rs (L427)). This is because it iterates over every Unit in the build graph checking the `outputs` for filenames. However, [`outputs`](835d5576e1/src/cargo/core/compiler/context/compilation_files.rs (L109-L110)) was missing the outputs for standard library units. That is because `outputs` is computed by walking the graph starting from the roots.
The bug here is that `attach_std_deps` was adding the standard library units to graph, even though they aren't reachable from the roots, thus creating orphans.
The solution is to avoid adding the standard library units if they are not needed (as is the case when building just a proc-macro).
Fixes#9828
Move `tmp` test directory.
The `tmp` directory added in #9375 was placed within the profile directory (such as `target/debug/tmp` or `target/release/tmp`). This causes problems for any cargo target (binary, test, etc.) with the name `tmp` as there is a name collision. This PR attempts to address that by moving the `tmp` directory to the root of the target directory (`target/tmp`), and reserving the profile name "tmp".
Fixes#9783
Determine packages to install prior to installing
Old logic (pseudocode)
```
for krate in to_install {
pkg = determine_pkg(krate);
install_pkg(pkg);
}
```
New logic
```
let pkgs = to_install.into_iter(|krate| determine_pkg(krate));
pkgs.into_iter(|pkg| install_pkg(pkg));
```
This has the short term benefit of dumping most error messages out earlier in the process (eg a typo in the second package name).
Longer term, it might help with #9741 - as only the second loop would be parallelized. First loop shouldn't be parallelized because it would lead to redundant registry/git updates.
Show feature resolver differences for dev-dependencies.
During the crater run for 2021, there was a package that failed to update in a confusing way. The issue is that a feature was removed in the new resolver, but only for a dev-dependency. The report displayed with `cargo fix --edition` did not say anything about that, so it took me a bit to figure it out. This changes it so that the report also includes changes to features of dev-dependencies. I honestly don't remember my thought process behind the original code.
For example, the offending package now says:
```
When building the following dependencies, the given features will no longer be used:
log v0.4.8 removed features: std
syn v0.15.44 (as host dependency) removed features: extra-traits, visit
The following differences only apply when building with dev-dependencies:
phf_shared v0.7.24 (as host dependency) removed features: unicase
```
And the error that happens after updating to 2021 is:
```
error[E0277]: the trait bound `UniCase<&str>: phf_shared::PhfHash` is not satisfied
--> /Users/eric/.cargo/registry/src/github.com-1ecc6299db9ec823/mime_guess-1.8.7/build.rs:37:21
|
37 | forward_map.entry(UniCase(key), &format!("{:?}", val));
| ^^^^^ the trait `phf_shared::PhfHash` is not implemented for `UniCase<&str>`
```
Hopefully developers will be able to see the note about the feature `unicase` being removed from `phf_shared`, and the error message about `UniCase` not implementing `PhfHash`, and connect the two together. Previously, the upgrade report didn't mention anything about `phf_shared`, and thus no clues on what went wrong.
Teach cargo to failfast on recursive/corecursive aliases
Eg.
[alias]
test-1 = test-2
test-2 = test-3
test-3 = test-1
Previously it would stack overflow
Pulled out non controversial bits from from #9768
Fix value-after-table error with profiles.
If the `strip`, `dir-name`, or `inherits` fields were included along with a profile override, then `cargo publish` would fail with a `ValueAfterTable` error because the fields were listed in the wrong order in the struct definition.
Fixes#9787
