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
The `anyhow` crate interoperates with the `std::error::Error` trait
rather than a custom `Fail` trait, and this is the general trend of
error handling in Rust as well.
Note that this is mostly mechanical (sed) and intended to get the test
suite passing. As usual there's still more idiomatic cleanup that can
happen, but that's left to later commits.
First reported in rust-lang/rust#65014 it looks like our error message
on cyclic dependencies may be confusing at times. It looks like this is
an issue because there are multiple paths through a graph for a
dependency, so using the generic `path_to_top` function isn't producing
the most useful path for this purpose.
We're already walking the graph though, so this commit adds an extra
parameter which collects the list of packages we've visited so far to
produce a hopefully always-accurate error message showing the chain of
dependencies end-to-end for what depends on what.
Refactor `Kind` to carry target name in `Target`
This commit is an internal refactoring of Cargo's compilation backend to
eventually support compiling multiple target simultaneously. The
original motivation for this came up in discussion of #7297 and this has
long been something I've intended to update Cargo for. Nothing in the
backend currently exposes the ability to actually build multiple target
simultaneously, but this should have no function change with respect to
all current consumers. Eventually we'll need to refactor APIs of how you
enter the compilation backend to compile for multiple targets.
This commit is an internal refactoring of Cargo's compilation backend to
eventually support compiling multiple target simultaneously. The
original motivation for this came up in discussion of #7297 and this has
long been something I've intended to update Cargo for. Nothing in the
backend currently exposes the ability to actually build multiple target
simultaneously, but this should have no function change with respect to
all current consumers. Eventually we'll need to refactor APIs of how you
enter the compilation backend to compile for multiple targets.
Extract Platform to a separate crate.
This moves the `Platform`, `Cfg`, `CfgExpr` types to a new crate named "cargo-platform". The intent here is to give users of `cargo_metadata` a way of parsing and inspecting cargo's platform values.
Along the way, I rewrote the error handling to remove `failure`, and to slightly improve the output.
I'm having doubts whether or not this is a good idea. As you can see from the `examples/matches.rs` example, it is nontrivial to use this (which also misses cargo's config values and environment variables). I don't know if anyone will actually use this. If this doesn't seem to have value, I would suggest closing it.
I've also included a sample script, `publish.py`, for publishing cargo itself. I suspect it will need tweaking, but I figure it would be a start and open for feedback.
Remove all `CARGO_*` env vars in tests
Usage of `CARGO_PROFILE_*` is generating unexpected warnings in tests in
rust-lang/rust#64316 so let's just blanket remove every env var that has
a `CARGO_*` prefix which generally means Cargo-specific env vars. Tests
practically all assume that they have blank configs right now.
Remove dependency on `winapi` 0.2
This commit removes Cargo's dependency on `winapi` 0.2 which takes an
excessively long time to build, slowing down Windows builds. The
`winapi` 0.2 crate was pulled in via a dependency chain that looked
like:
cargo
\- crates-io
\- http
\- bytes
\- iovec
\- winapi 0.2
The fix implemented here was to remove the `http` crate dependency from
`crates-io` which is only used for rendering status codes, but it's easy
enough to inline that function locally.
This commit removes Cargo's dependency on `winapi` 0.2 which takes an
excessively long time to build, slowing down Windows builds. The
`winapi` 0.2 crate was pulled in via a dependency chain that looked
like:
cargo
\- crates-io
\- http
\- bytes
\- iovec
\- winapi 0.2
The fix implemented here was to remove the `http` crate dependency from
`crates-io` which is only used for rendering status codes, but it's easy
enough to inline that function locally.
Usage of `CARGO_PROFILE_*` is generating unexpected warnings in tests in
rust-lang/rust#64316 so let's just blanket remove every env var that has
a `CARGO_*` prefix which generally means Cargo-specific env vars. Tests
practically all assume that they have blank configs right now.
Only run these tests on one CI builder (not all platforms) though. This
is extremely resource intensive since it rebuilds libstd. Currently this
does not share a build directly like before because the number of tests
are supposed to be small, but if necessary we can add that in later too.
