Optimize runtime of `#[cargo_test_macro]`
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!
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!
Don't fail if we can't acquire readonly lock
This commit updates support from #6940 to not only gracefully handle
situations where the lock can be acquired in readonly but not read/write
mode but also handle situations where even a readonly lock can't be
acquired. If a readonly lock can't be acquired (and the read/write
failed) then we likely can't touch anything in the directory, so there's
no value gained from locking anyway.
Closes#7147
This commit updates support from #6940 to not only gracefully handle
situations where the lock can be acquired in readonly but not read/write
mode but also handle situations where even a readonly lock can't be
acquired. If a readonly lock can't be acquired (and the read/write
failed) then we likely can't touch anything in the directory, so there's
no value gained from locking anyway.
Closes#7147
Add support for multiple --features options
Closes#7076
Pretty straightforward, but I added an extra test to make sure that space-separated features work in conjunction with multiple --features options.
Add a way to disable all nightly tests
One thing I'm realizing now is that we test a number of nightly features
of Cargo/rustc, but if they change in rustc then because
rust-lang/rust's CI run's Cargo's tests it could prevent those changes
from landing! The purpose of running Cargo's tests in CI in
rust-lang/rust is to ensure that Cargo generally works, but there's no
need to test the nightly features as that's Cargo's job.
As a result this adds an environment variable that will be set from
rust-lang/rust's CI which will disable these tests.
One thing I'm realizing now is that we test a number of nightly features
of Cargo/rustc, but if they change in rustc then because
rust-lang/rust's CI run's Cargo's tests it could prevent those changes
from landing! The purpose of running Cargo's tests in CI in
rust-lang/rust is to ensure that Cargo generally works, but there's no
need to test the nightly features as that's Cargo's job.
As a result this adds an environment variable that will be set from
rust-lang/rust's CI which will disable these tests.
Update mdbook to 0.3.
This updates to mdbook 0.3 which uses relative links, which are much better
(the pages mostly work when viewing on GitHub for example).
Remove unused feature filter.
NOTE: Do not merge this lightly. This upended my understanding of how the resolver handles features, and I'm still not sure about it.
Remove an unused check that an optional dependency is activated.
This was originally added 4 years ago in #1812, during a time when this code iterated over the actual dependencies from `Package.dependencies()`. In #5415 this was refactored so that it gets the `deps` list directly from the Resolver, which AFAIK has already filtered out the features. IIUC, this filtering is done [here](705009eb38/src/cargo/core/resolver/dep_cache.rs (L270-L272)).
Also ignore remap-path-prefix in metadata for `cargo rustc`.
Also ignore `--remap-path-prefix` in `cargo rustc`. Who knew that `BuildContext` had 3 sets of arguments?
Closes#7133
Fix some formatting for some strings.
Some of these strings were formatted in a strange way by rustfmt.
Also fixed some strings missing trailing backslashes. Specifically, the "path override for crate" string, and the strings in `http_auth_offered`.
Handle activation conflicts for `[patch]` sources
This commit updates the resolver to ensure that it recognizes conflicts
when `[patch]` is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when `[patch]` was used.
This meant that when you used `[patch]` it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of `[patch]`!
The fix here is to catch this use case happening, when a `Dependency`
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.
Closes#7117
This commit updates the resolver to ensure that it recognizes conflicts
when `[patch]` is used to augment an older version of what's already in
a source, for example. Previously the deduplication based on
semver-compatible versions didn't actually work when `[patch]` was used.
This meant that when you used `[patch]` it might not transitively affect
the entire crate graph, instead just giving you a version of a
dependency and everyone else. This violates the intention of `[patch]`!
The fix here is to catch this use case happening, when a `Dependency`
source specification mismatches an activated package we need to list a
second activation in the resolver to prevent major versions from being
selected from both the original source as well as the source of the id.
Closes#7117
Update dependencies
This removes the `byteorder`-dependency, which was used in a few tests only anyway and is not needed since 1.32; also removes the `derive`-feature from the `failure`-crate, which is not needed also.
Fix overwriting .d file for binary with dSYM on apple targets.
When building a binary on targets containing `-apple-`, the resulting `.d` file gets overwritten with the dependencies of the `.dSYM` file. Eg. in the changed unit test, `foo.d` would start with `p.bin(foo).with_extension("dSYM")` instead of `p.bin(foo)`.
This PR fixes that problem by not generating `.d` dependency information files for outputs of the `DebugInfo` flavor.
Revert "Fix 'getting started' internal links"
This reverts commit 60f25f56b8f398e935d7e8d952c4c2e6cc0bc7d5 (#7093).
Cargo currently uses mdbook 0.1, so the links were correct.
