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.
Serialize `cargo fix`
This changes `cargo fix` so that it only fixes one crate at a time. Previously, it would allow concurrent fixing across packages. This caused a problem if a workspace uses things like `#[path]` or `include!()` of a shared file between packages. A real-world example of this is serde, which has [this](9c39115f82/serde_derive_internals/lib.rs (L43-L45)) which reuses the some source files between the `serde` and `serde_derive` packages. Modifying those files concurrently causes corruption and the fix will fail.
Closes#6528
This works by introspecting rustc's error output, using the JSON format
to determine whether it's a warning or error, then skipping it
altogether if it's a summary of the diagnostics printed.
Before:
```
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: aborting due to 2 previous errors; 1 warning emitted
error: could not compile `wrong`
```
After:
```
$ cargo check --message-format short
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: could not compile `wrong` due to 2 previous errors; 1 warning emitted
```
Fix rustc/rustdoc config values to be config-relative.
The `rustc`, `rustdoc`, `rustc_wrapper`, and `rustc_workspace_wrapper` config values (in the `[build]` table) were being interpreted literally. This caused a problem if you used a relative path like `foo/rustc`. This would be interpreted as a relative path from whatever cwd cargo launches rustc from, which changes for different scenarios, making it essentially unusuable (since crates.io dependencies wouldn't be buildable).
Additionally, due to https://github.com/rust-lang/rust/issues/37868, it is a bad idea to use relative paths.
This changes it so that those paths are config-relative. Bare names (like "my-rustc-program") still use PATH as before.
This also includes a commit to centralize the rustc-wrapper program used by several tests so that it isn't built multiple times (and to allow several tests to work on windows).
Fixes#8202
This attempts to centralize all the edition stuff in one place (the
`Edition` enum) so that adding a new edition or stabilizing one should
be relatively little work (and more importantly, we don't miss things).
Importantly, this changes `cargo new` to default to the latest stable.
It also changes the `cargo fix --edition-idiom` behavior to only apply
idioms for the *current* edition.
* `--edition` always means "next" edition.
* `--edition` when on the most recent edition is not an error, just a warning.
* Support fix to 2021 edition.
What was previously "Fixing" was a message for after the fixes had
been applied. I think it would be clearer if it said "Fixed",
to indicate that the fixes had actually finished.
The new "Fixing" is posted just before it starts. This is verbose-only
since it is a little noisy.
Generalized `clippy_is_available` and renamed as `command_is_available`.
No checks in `ignores_failure_to_format_source`, it's not supposed to
use `rustfmt` even if it's available
Cargo has of #7143 enabled pipelined compilation by default which
affects how the compiler is invoked, especially with respect to JSON
messages. This, in some testing, has proven to cause quite a few issues
with rustbuild's current integration with Cargo. This commit is aimed at
adding features to Cargo to solve this issue.
This commit adds the ability to customize the stream of JSON messages
coming from Cargo. The new feature for Cargo is that it now also mirrors
rustc in how you can configure the JSON stream. Multiple
`--message-format` arguments are now supported and the value specified
is a comma-separated list of directives. In addition to the existing
`human`, `short`, and `json` directives these new directives have been
added:
* `json-render-diagnostics` - instructs Cargo to render rustc
diagnostics and only print out JSON messages for artifacts and Cargo
things.
* `json-diagnostic-short` - indicates that the `rendered` field of rustc
diagnostics should use the "short" rendering.
* `json-diagnostic-rendered-ansi` - indicates that the `rendered` field of rustc
diagnostics should embed ansi color codes.
The first option here, `json-render-diagnostics`, will be used by
rustbuild unconditionally. Additionally `json-diagnostic-short` will be
conditionally used based on the input to rustbuild itself.
This should be enough for external tools to customize how Cargo is
invoked and how all kinds of JSON diagnostics get printed, and it's
thought that we can relatively easily tweak this as necessary to extend
it and such.
