test: fix race in cargo_compile_with_invalid_code_in_deps by Functionhx · Pull Request #17203 · rust-lang/cargo

Functionhx · 2026-07-11T20:02:58Z

Parallel compilation of multiple failing dependency crates can
produce different stderr output depending on which finishes first.
Replaced exact with_stderr_data assertion with with_stderr_contains
partial patterns to eliminate the race.

…_in_deps Replace with_stderr_data (exact unordered match) with with_stderr_contains (partial patterns) in the cargo_compile_with_invalid_code_in_deps test. The test previously expected both "bar" and "baz" compilation errors in the output. Due to a race condition in parallel compilation, one job can finish before the other starts, producing only one error and causing the test to fail flakily with the second error line missing. Using with_stderr_contains with partial patterns ([..]) ensures the test passes regardless of whether one or both compilation errors appear. Fixes: #17161 Signed-off-by: Functionhx <[email protected]>

rustbot · 2026-07-11T20:03:02Z

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @weihanglo (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ehuss, @epage, @weihanglo
@ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
Random selection from ehuss, epage, weihanglo

ehuss · 2026-07-11T21:44:03Z

This won't fix the problem, because it is still checking for both crates to be built.

weihanglo · 2026-07-11T21:58:22Z

-"#]]
-            .unordered(),
-        )
+        .with_stderr_contains("[COMPILING] bar v0.1.0 [..]")


Thanks for the contribution.

We probably don't want to go back and use contains methods. Please see

cargo/crates/cargo-test-support/src/compare.rs

Lines 3 to 7 in 2ceefa0

//! # Deprecated comparisons

//!

//! Cargo's tests are in transition from internal-only pattern and normalization routines used in

//! asserts like [`crate::Execs::with_stdout_contains`] to [`assert_e2e`] and [`assert_ui`].

//!

and

cargo/crates/cargo-test-support/src/lib.rs

Lines 807 to 822 in 2ceefa0

/// Verifies that stderr contains the given contiguous lines somewhere in

/// its output.

///

/// See [`compare`] for supported patterns.

///

/// <div class="warning">

///

/// Prefer [`Execs::with_stderr_data`] where possible.

/// - `expected` cannot be snapshotted

/// - `expected` can end up being ambiguous, causing the assertion to succeed when it should fail

///

/// </div>

pub fn with_stderr_contains<S: ToString>(&mut self, expected: S) -> &mut Self {

self.expect_stderr_contains.push(expected.to_string());

self

}

Have you reproduced it? Could you find other means to fix it, for example with -j1?

View changes since the review

Thanks. Switched to -j1 to force serial compilation and restored with_stderr_data -- makes the output deterministic without needing partial matches. PTAL.

The other way is this:

[COMPILING] ba[..] v0.1.0 ([ROOT]/ba[..]) ... [ERROR] could not compile `ba[..]` (lib) due to 1 previous error ...

It may work even without -j1. I haven't checked why this test needs two dependencies though.

rustbot · 2026-07-11T21:58:30Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Functionhx · 2026-07-12T02:04:57Z

Thanks for catching that. I've updated the fix to only check for bar's COMPILING message (removed the baz COMPILING check). The test now verifies that at least one dep compiled and the build errored, without depending on which order the parallel jobs finish.

Functionhx

You're right — bar and baz are independent deps, Cargo selects ready units from a hash map with no ordering guarantee. Changed to check for [..]invalid rust code[..] which doesn't depend on which crate compiles first. PTAL.

View changes since this review

weihanglo · 2026-07-12T03:06:53Z

Please see my previous comment #17203 (comment)

View changes since the review

Thanks, I misunderstood the main concern.I'll deepseek!

…pile_with_invalid_code_in_deps Replace with_stderr_contains (deprecated, checks for both bar and baz) with -j1 for serial compilation and with_stderr_data using ba[..] wildcards so the test only checks for one dep's COMPILING and ERROR messages, not both. Fixes #17161 Signed-off-by: Yuchen Fan <[email protected]>

Functionhx · 2026-07-12T17:00:56Z

Tested both variants locally (Linux x86-64, 32-core, rustc 1.91.0):

with -j1: 100/100 passed
without -j1: 0/100 passed — deterministic failure, bar/baz COMPILING messages interleave in parallel build on 32 cores

The -j1 is necessary because the assertion depends on stderr ordering. I can share full stderr if useful.

weihanglo

Thanks!

View changes since this review

Update cargo submodule 29 commits in 59800466c5c41c444d264b1010b4d57e85a7117f..3efb1f477e99b42974b982d939fd100303cdf7db 2026-07-07 15:52:22 +0000 to 2026-07-17 23:53:19 +0000 - refactor(context): normalize in `homedir` instead (rust-lang/cargo#17222) - chore(ci): reflect doc folder move in book deployment (rust-lang/cargo#17235) - refactor(ops): Have cargo-metadata's ops match the command name (rust-lang/cargo#17233) - chore: Flatten src (rust-lang/cargo#17231) - chore: Flatten `src` (rust-lang/cargo#17230) - chore(ci): remove stale libsecret packages (rust-lang/cargo#17229) - perf: Lazily initialize git2 fetch transports (rust-lang/cargo#17226) - test(trim-paths): re-enable lldb debugger tests (rust-lang/cargo#17223) - Include SBOM outputs in fingerprints (rust-lang/cargo#17216) - Update cfg_aliases to 0.2.2 (rust-lang/cargo#17225) - test(trim-paths): exercise GDB on windows-gnu (rust-lang/cargo#17221) - feat(profile): Disable incremental compilation under CI by default (rust-lang/cargo#17220) - Remove myself from review rotation (rust-lang/cargo#17219) - Fix typo in comment in sync (rust-lang/cargo#17217) - docs(ref): Improve handing of built-in profiles (rust-lang/cargo#17213) - fix: dont apply host-config gating to stable behavior (rust-lang/cargo#17198) - chore(deps): update msrv (rust-lang/cargo#17192) - test: fix race in cargo_compile_with_invalid_code_in_deps (rust-lang/cargo#17203) - Rename `-Zno-embed-metadata` to `-Zembed-metadata=no` (rust-lang/cargo#17149) - fix(source): incorrect duplicate package warning (rust-lang/cargo#17204) - Fix manifest schema generation: `TomlDebugInfo` enum-variants doesn't renamed (rust-lang/cargo#17202) - Reduce library search path length in new build dir layout (rust-lang/cargo#17191) - fix(install): Move --debug to Compilation options (rust-lang/cargo#17199) - chore(ci): dogfood `build.warnings` (rust-lang/cargo#17195) - docs(lints): Better match clippy in lint section titles (rust-lang/cargo#17190) - chore: bump to 0.100.0; update changelog (rust-lang/cargo#17189) - docs(ref): Clarify MSRV for lints (rust-lang/cargo#17184) - docs(report): add missing entry for `cargo report future-incompatibilities` (rust-lang/cargo#17188) - Reduce rustc `-L` args used in the new `build-dir` layout (rust-lang/cargo#17168)

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 11, 2026

rustbot assigned weihanglo Jul 11, 2026

weihanglo requested changes Jul 11, 2026

View reviewed changes

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 11, 2026

rustbot added the S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. label Jul 11, 2026

Functionhx force-pushed the fix/17161-race-test branch from 3d72d0a to c37011d Compare July 12, 2026 02:04

Functionhx force-pushed the fix/17161-race-test branch from c37011d to 6eeb071 Compare July 12, 2026 02:54

Functionhx commented Jul 12, 2026

View reviewed changes

weihanglo reviewed Jul 12, 2026

View reviewed changes

Functionhx force-pushed the fix/17161-race-test branch from 6eeb071 to f0a9c26 Compare July 12, 2026 03:20

Functionhx force-pushed the fix/17161-race-test branch from f0a9c26 to a12c2c7 Compare July 12, 2026 16:00

weihanglo approved these changes Jul 12, 2026

View reviewed changes

weihanglo added this pull request to the merge queue Jul 12, 2026

Merged via the queue into rust-lang:master with commit 24e0f7d Jul 12, 2026
29 checks passed

weihanglo mentioned this pull request Jul 18, 2026

Update cargo submodule rust-lang/rust#159475

Merged

rustbot added this to the 1.99.0 milestone Jul 18, 2026

	//! # Deprecated comparisons
	//!
	//! Cargo's tests are in transition from internal-only pattern and normalization routines used in
	//! asserts like [`crate::Execs::with_stdout_contains`] to [`assert_e2e`] and [`assert_ui`].
	//!

	/// Verifies that stderr contains the given contiguous lines somewhere in
	/// its output.
	///
	/// See [`compare`] for supported patterns.
	///
	/// <div class="warning">
	///
	/// Prefer [`Execs::with_stderr_data`] where possible.
	/// - `expected` cannot be snapshotted
	/// - `expected` can end up being ambiguous, causing the assertion to succeed when it should fail
	///
	/// </div>
	pub fn with_stderr_contains<S: ToString>(&mut self, expected: S) -> &mut Self {
	self.expect_stderr_contains.push(expected.to_string());
	self
	}

Uh oh!

Uh oh!

Conversation

Functionhx commented Jul 11, 2026

Uh oh!

rustbot commented Jul 11, 2026

Uh oh!

ehuss commented Jul 11, 2026

Uh oh!

weihanglo Jul 11, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Functionhx Jul 12, 2026

Choose a reason for hiding this comment

Uh oh!

weihanglo Jul 12, 2026

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jul 11, 2026

Uh oh!

Functionhx commented Jul 12, 2026

Uh oh!

Functionhx left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

weihanglo Jul 12, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Functionhx Jul 12, 2026

Choose a reason for hiding this comment

Uh oh!

Functionhx commented Jul 12, 2026

Uh oh!

weihanglo left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

weihanglo Jul 11, 2026 •

edited by rustbot

Loading

Functionhx left a comment •

edited by rustbot

Loading

weihanglo Jul 12, 2026 •

edited by rustbot

Loading

weihanglo left a comment •

edited by rustbot

Loading