Skip to content
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

Merged
merged 1 commit into from
Dec 18, 2024

Conversation

weihanglo
Copy link
Member

@weihanglo weihanglo commented Dec 16, 2024

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 users CARGO_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:

---- test_proc_macro stdout ----
running `/home/runner/work/cargo/cargo/target/debug/cargo fetch -Zbuild-std -Zpublic-dependency`
running `/home/runner/work/cargo/cargo/target/debug/cargo test --lib -Zbuild-std -Zpublic-dependency`
thread 'test_proc_macro' panicked at tests/build-std/main.rs:394:10:

---- expected: tests/build-std/main.rs:388:27
++++ actual:   stderr
        1 + [BLOCKING] waiting for file lock on package cache
error: test failed, to rerun pass `-p cargo --test build-std`
        2 + [BLOCKING] waiting for file lock on package cache
   1    3 | [COMPILING] foo v0.0.0 ([ROOT]/foo)
   2    4 | [FINISHED] `test` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
   3    5 | [RUNNING] unittests src/lib.rs (target/debug/deps/foo-[HASH])

@weihanglo weihanglo added the Z-build-std Nightly: build-std label Dec 16, 2024
@rustbot
Copy link
Collaborator

rustbot commented Dec 16, 2024

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 16, 2024
Copy link
Member

@Muscraft Muscraft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@Muscraft Muscraft added this pull request to the merge queue Dec 17, 2024
@Muscraft Muscraft removed this pull request from the merge queue due to a manual request Dec 17, 2024
@epage epage changed the title test(build-std): isolate tests for asserting complete error messages test(build-std): Isolate output test to avoid spurious [BLOCKING] messages from concurrent runs Dec 17, 2024
Comment on lines 45 to 63
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;
Copy link
Contributor

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?

Comment on lines 118 to 120
// 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// 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

@weihanglo weihanglo force-pushed the build-std-test branch 2 times, most recently from 4159d5b to 9fedef7 Compare December 17, 2024 23:40
…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.
@epage epage enabled auto-merge December 17, 2024 23:45
@epage epage added this pull request to the merge queue Dec 18, 2024
Merged via the queue into rust-lang:master with commit 8682bb4 Dec 18, 2024
20 checks passed
github-merge-queue bot pushed a commit that referenced this pull request Dec 18, 2024
### 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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 18, 2024
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)
@rustbot rustbot added this to the 1.85.0 milestone Dec 18, 2024
@weihanglo weihanglo deleted the build-std-test branch December 19, 2024 22:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. Z-build-std Nightly: build-std
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants