-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test(build-std): Isolate output test to avoid spurious [BLOCKING]
messages from concurrent runs
#14943
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
[BLOCKING]
messages from concurrent runs
tests/build-std/main.rs
Outdated
fn build_std(&mut self) -> &mut Self; | ||
fn build_std_arg(&mut self, arg: &str) -> &mut Self; | ||
fn build_std_isolated(&mut self) -> &mut Self; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we document when to use each?
tests/build-std/main.rs
Outdated
// An isolated CARGO_HOME environment is used elesewhere in this test | ||
// to ensure no extra index updates is performed. | ||
// It is achieve by asserting the complete stderr without any wildcard. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// An isolated CARGO_HOME environment is used elesewhere in this test | |
// to ensure no extra index updates is performed. | |
// It is achieve by asserting the complete stderr without any wildcard. | |
// HACK: use an isolated the isolated CARGO_HOME environment (`build_std_isolated`) to avoid `[BLOCKING]` messages (from lock contention with other tests) from getting in this test's asserts |
4159d5b
to
9fedef7
Compare
…sages from concurrent runs 47c2095 didn't really fix the flakiness. build-std tests use the users `CARGO_HOME` for downloading registry dependencies of the standard library. This reduces disk needs of the tests, speeds up the tests, and reduces the number of network requests that could fail. However, this means all of the tests access the same locks for the package cache. In one test, we assert on the output and a `[BLOCKING]` message can show up, depending on test execution time from concurrent test runs. We are going to hack around this by having the one test that asserts on test output to use the standard `cargo-test-support` `CARGO_HOME`, rather than the users `CARGO_HOME`. There will then only be one process accessing the lock and no `[BLOCKING]` messages.
9fedef7
to
ca59614
Compare
### What does this PR try to resolve? Blocked on <#14943> (or can just merge this one). Fixes #14935 #14935 failed because since 125e873 [`std_resolve`][1] only includes `sysroot` as primary package. When any custom Cargo feature is provided via `-Zbuild-std-feature`, the default feature set `panic-unwind` would be gone, so no `panic_unwind` crate presents in `std_resolve`. When then calling [`std_resolve.query`][2] with the default set of crates from [`std_crates`][3], which automatically includes `panic_unwind` when `std` presents, it'll result in spec not found because `panic_unwind` was not in `std_resolve` anyway. [1]: https://github.com/rust-lang/cargo/blob/addcc8ca715bc7fe20df66afd6efbf3c77ef43f8/src/cargo/core/compiler/standard_lib.rs#L96 [2]: https://github.com/rust-lang/cargo/blob/addcc8ca715bc7fe20df66afd6efbf3c77ef43f8/src/cargo/core/compiler/standard_lib.rs#L158 [3]: https://github.com/rust-lang/cargo/blob/addcc8ca715bc7fe20df66afd6efbf3c77ef43f8/src/cargo/core/compiler/standard_lib.rs#L156 ### How should we test and review this PR? This patch is kinda a revert of 125e873 in terms of the behavior. With this, now `std_resolve` is always resolved to the same set of packages that Cargo will use to generate the unit graph, (technically the same set of crates + `sysroot`), by sharing the same set of primary packages via `std_crates` functions. Note that when multiple `--target`s provided, if std is specified or there is one might support std, Cargo will always resolve std dep graph. To test it manually, run ``` RUSTFLAGS="-C panic=abort" cargo +nightly-2024-12-15 b -Zbuild-std=std,panic_abort -Zbuild-std-features=panic_immediate_abort ``` change to this PR's cargo with the same nightly rustc, it would succeed. I am a bit reluctant to add an new end-2end build-std test, but I still did it. A bit scared when mock-std gets out-of-sync of features in std in rust-lang/rust.
Update cargo 6 commits in 769f622e12db0001431d8ae36d1093fb8727c5d9..99dff6d77db779716dda9ca3b29c26addd02c1be 2024-12-14 04:27:35 +0000 to 2024-12-18 00:55:17 +0000 - fix(build-std): make Resolve align to what to build (rust-lang/cargo#14938) - test(build-std): Isolate output test to avoid spurious `[BLOCKING]` messages from concurrent runs (rust-lang/cargo#14943) - docs: fix wrong changelog PR link (rust-lang/cargo#14947) - docs(unstable): Correct stabilization version for MSRV-resolver (rust-lang/cargo#14945) - Update release information for home 0.5.11 (rust-lang/cargo#14939) - Limit release trigger to 0.* tags (rust-lang/cargo#14940)
What does this PR try to resolve?
47c2095 didn't really fix the flakiness.
Spun off from #14938 2a54190
build-std tests use the users
CARGO_HOME
for downloading registry dependencies of the standard library.This reduces disk needs of the tests, speeds up the tests, and reduces the number of network requests that could fail.
However, this means all of the tests access the same locks for the package cache. In one test, we assert on the output and a
[BLOCKING]
message can show up, depending on test execution time from concurrent test runs.We are going to hack around this by having the one test that asserts on test output to use the standard
cargo-test-support
CARGO_HOME
, rather than the usersCARGO_HOME
. There will then only be one process accessing the lock and no[BLOCKING]
messages.How should we test and review this PR?
No more assertion errors like this: