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.
I've noticed recently that the incremental compile time for our test
suite has felt like it's increased quite a bit. I think one reason is
that everything has to go through `#[cargo_test_macro]` unconditionally
on all incremental builds, and wow do we have a lot of tests being
pumped through that macro.
Instrumenting the macro a little bit shows that we spend nearly 2.5
seconds on each compilation simply executing this macro (note that it's
in debug mode as well, not release since we typically don't execute
tests in release mode.
This commit instead drops the usage of `syn` and `quote` in favor of a
"raw procedural macro" which is much more optimized for just our use
case, even in debug mode. This drops the collective time spent in the
macro to 0.2 seconds, even in debug mode!
Resolver test/debug cleanup
This is several small things salvaged from abandoned PRs and implemented on top of #7011
In working on this I noted that the prop tests are very sensitive to whether backtrace are turned on. Maybe we should set that env to 0 for that builder?
These tests take a good amount of time to run locally and they're also
causing a lot of dependencies to get pulled into rust-lang/rust, so
let's have a separate crate that we just test on our own CI
