Enable Cargo's new build-dir layout by ranger-ross · Pull Request #155439 · rust-lang/rust

ranger-ross · 2026-04-17T13:50:00Z

This PR enables the new Cargo build-dir layout in boostrap builds with -Zbuild-dir-new-layout.

See: #t-infra/bootstrap > Has anyone tested `./x` with the new build-dir layout?

weihanglo · 2026-04-17T13:59:14Z

    // got a list of prefix/extensions and we basically just need to find the
-    // most recent file in the `deps` folder corresponding to each one.
-    let contents = target_deps_dir
+    // most recent file in the `build` folder corresponding to each one.


Not yet read the code by myself. Just wonder why bootstrap are doing this? And if bootstrap needs to do it, it should be a feature in Cargo, at least a (perma-)unstable feature.

View changes since the review

See the commit block around line 2374. Basically we need the non-uplifted name that contains the unique hash. The artifact notifications provide the uplifted name where possible.

ranger-ross · 2026-04-17T15:28:43Z

+    //
+    // Cargo's build folder is structured as `build/<pkg>/<hash>/out/<artifacts>` so
+    // we need to traverse multiple directory layers to get to actual files.
+    let read_dir = |path: &Path| path.read_dir().ok().into_iter().flatten().filter_map(Result::ok);


checks failed because if there are any lingering files/dirs in <build-dir>/<target>/build that are not using the new layout it panics.

Update the original code to not panic if we call .read_dir() on a non-directory. Lets see if CI is happy with this

View changes since the review

ranger-ross · 2026-04-19T12:01:59Z

Looks like the miri job timed out.
Out of curiosity, how stable is this job?

(Sorry, haven't touch the rl/r repo much so I wondering if the failure is related to the new layout or if its normal for spurious failures)

mati865 · 2026-04-19T12:48:31Z

x86_64 Linux jobs rarely hang, I've retried it to be sure.

ranger-ross · 2026-04-19T15:34:48Z

Okay it's hanged on both runs so it's probably the changes.

Is there a way for me to run this check on my machine? I was trying to parse through the GitHub actions to see what command is being run but I was struggling to find it.

weihanglo · 2026-04-19T15:46:14Z

@ranger-ross see https://rustc-dev-guide.rust-lang.org/tests/docker.html#testing-with-docker

cargo run --manifest-path src/ci/citool/Cargo.toml run-local x86_64-gnu-miri

This is the easiest way to run it locally.

ranger-ross · 2026-04-20T14:09:41Z

Okay, so I did some testing and locally it runs fine. (takes around ~20 mins on my machine)

After looking a bit closer at the job logs, it actually never got stuck.
It just take WAY longer than normal....
According to the github stats x86_64-gnu-miri normally takes ~58 mins to run, but we took over 6 hrs and hit the timeout.

Looking at the other jobs, most of them did not have a large perf regression (except x86_64-gnu-tools which was also pretty bad)

That is concerning... 😅

rustbot · 2026-04-27T15:15:47Z

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in src/tools/compiletest

cc @jieyouxu

ranger-ross · 2026-04-27T15:27:49Z

I realized the issue is not with the speed of compilation, but rather that for some reason in CI the compiler (and many other units) are being re-built multiple times which slows everything down and times out.

I haven't figured out why yet. While testing the CI on my fork, I've noticed its inconsistent and sometimes everything only builds once. I'm still investigating why this could be happening. rust-lang/cargo#16345 comes to mind as something that might change this behavior, but I am still unsure whats happening.

I went ahead and pushed some new changes with more fixes for tests and cranelift.

I'll continue investigating this week, but any rl/r experts see any obvious issues with my changes lmk
@rustbot author

ytmimi · 2026-04-27T21:40:03Z

-    // Chop off `deps`.
+    // Chop off `out`.
+    me.pop();
+    // Chop off `<hash>`.
+    me.pop();
+    // Chop off `<pkgname>`.
+    me.pop();
+    // Chop off `build`.


Is this going to break things in rustfmt's CI when we do a subtree push?

View changes since the review

ahh yeah it would probably break, maybe better for me to remove that from this PR and raise a separate PR in the rustfmt repo?

I'm still trying to understand what changes we need in this PR verse what changes can be split out into smaller more targeted changes

In that case, I'd prefer we open up a PR to add the new cargo build dir layout support to rustfmt directly and verify that things are working before making any changes to the rustfmt subtree here in r-l/rust

fair enough. I tested on my fork and I think rust-lang/rust CI fails with out rustfmt changes.

I went ahead and opened rust-lang/rustfmt#6879

@ranger-ross If you're able to duplicate the rustfmt code changes you made in rust-lang/rustfmt#6879 here that would be great.

I added those commits to this PR. I also noticed that RUSTFLAGS: -D warning was missing from the github actions workflows in rust-lang/rust so I went ahead and added that while I was at it. I guess it doesn't matter for this repo but oh well.

We've recently made some changes to those CI files in rustfmt so it's possible that the RUSTFLAGS: -D warning changes just haven't been synced up yet, but I don't think there's any issue in explicitly including that here.

This also syncs `RUSTFLAGS: -D warnings` which is added in rust-lang/rustfmt

rustbot · 2026-06-19T14:09:22Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

ranger-ross · 2026-06-19T14:10:34Z

@bors try jobs=x86_64-msvc-ext1

rust-bors · 2026-06-19T16:39:47Z

☀️ Try build successful (CI)
Build commit: efd5bf1 (efd5bf1b4495b0894eace2381078876673f8b432)
Base parent: 0c1748c (0c1748ce7c56091b659757e488dbaf782b814137)

ranger-ross · 2026-06-19T16:44:42Z

@bors try jobs=x86_64-msvc-1

rust-bors · 2026-06-19T19:09:52Z

💔 Test for e07d099 failed: CI. Failed job:

try - x86_64-msvc-1 (web logs, enhanced plaintext logs)

This is an optimization to reduce the amount for paths that get added to the dylib search path. This is especially important for Windows as it has issues when PATH gets too long. With the new Cargo build-dir we increased the number of paths being passed.

ranger-ross · 2026-06-20T03:29:22Z

@bors try jobs=x86_64-msvc-1,x86_64-msvc-ext1

rust-bors · 2026-06-20T06:18:08Z

☀️ Try build successful (CI)
Build commit: 5edfdba (5edfdbaef81d9050f7642bdcebbaa8d081df3186)
Base parent: 32ea361 (32ea3615cc027bcb8fd720c7511ffb484f6223a3)

ranger-ross · 2026-06-20T07:19:59Z

Okay, I think now the windows CI is looking good.

Tracking down the issue was a bit difficult but the fix is relatively straight forward.
In the new layout, we pass more -L flags use build units get thier own dir for the compiler output.
On windows the command length is limited to about ~32K including env vars like PATH.
Also windows uses PATH for searching during dylib linking. During rustc appends all of the dependency paths (-L) to PATH.

rust/compiler/rustc_interface/src/passes.rs

Lines 167 to 171 in 8c75e93

    
           // Windows dlls do not have rpaths, so they don't know how to find their 
        
           // dependencies. It's up to us to tell the system where to find all the 
        
           // dependent dlls. Note that this uses cfg!(windows) as opposed to 
        
           // targ_cfg because syntax extensions are always loaded for the host 
        
           // compiler, not for the target.

With the new layout, the increased PATH length gets too long and hits the windows limit causing a failure.
In our case the #[cargo_test] proc macro was failing to run rustc -V, but it would fail to spawn any process.

The fix in 093a8ac changes the logic in rustc to only add native dependency types to the PATH meaning that all of the dependency paths with just an rlib aren't added greatly reducing the size.
I think this should be safe and both Cargo and rustc's test suites pass on windows with the change, but let me know if I am over looking something here.

Hopefully the third r plus is the charm 🙏

@rustbot ready

bjorn3 · 2026-06-20T08:02:44Z

That commit would break if proc-macros ever get the ability to depend on rust dylibs, right?

ranger-ross · 2026-06-20T08:16:07Z

That commit would break if proc-macros ever get the ability to depend on rust dylibs, right?

Correct, we'd need a smarter way add the paths without exploding the PATH on Windows

weihanglo · 2026-06-20T11:36:21Z

Should we See the limitation of proc-macro loading rdylib as a blocker, or should we just go?

ranger-ross · 2026-06-20T12:01:33Z

@bjorn3 reached out and mentioned they would not be available to review over the few days and suggested I request a review from someone in T-bootstrap.

r? @Kobzol

edit:

Kobzol is not on the review rotation at the moment.

oops, didn't realize I should have checked the review rotation, feel free to reassign

rustbot · 2026-06-20T12:01:38Z

Kobzol is not on the review rotation at the moment.
They may take a while to respond.

Kobzol · 2026-06-21T08:13:51Z

You don't really have to check it, the review rotation mostly prevents auto assignment, but you can still r? people individually. It's mostly a warning to let people know that the reviewer might not be available. I am available (just don't want to join the rotation atm), maybe we should allow configuring the warning.

Anyway, I'll take a look.

Kobzol

The argfile stuff is pretty annoying :( Windows strikes back again, I guess. I wonder if we should add some path placeholders to rustc, so that you could say something like --placeholder=FOO=/very/long/path -L[FOO]/d/e -L[FOO]/d/e 😆

Left some comments related to bootstrap.

View changes since this review

Kobzol · 2026-06-21T08:15:34Z

+/// This is useful as we have some commands that can get very long and at times
+/// hit the OS limit (usually Windows)
+///
+/// This implementation is based off the of `ProcessBuilder` implementation in Cargo


Suggested change

/// This implementation is based off the of `ProcessBuilder` implementation in Cargo

/// This implementation is based off the `ProcessBuilder` implementation in Cargo

Kobzol · 2026-06-21T08:15:44Z

+/// but simplified.
+///
+/// NOTE: In most scenarios we want to avoid arg files as it makes debugging more complicated
+///       so we try to avoid it if the command is not close the the OS limit.


Suggested change

/// so we try to avoid it if the command is not close the the OS limit.

/// so we try to avoid it if the command is not close to the OS limit.

Kobzol · 2026-06-21T08:16:11Z

+}
+
+impl ArgFileCommand {
+    #[track_caller]


This attribute is mostly useless, because this call can't really panic, right?

yeah, I can remove. That was a carry over from the Cargo impl that should probably should have removed

Kobzol · 2026-06-21T08:29:19Z

 toml = "0.5"
 walkdir = "2.4"
 xz2 = "0.1"
+tempfile = "3.15.0"


This adds ~10 new dependencies to bootstrap, which is a bit unfortunate, we have been trying to avoid depending on tempfile before. But for the rustc.rs usage we'd have to pre-generate a temporary directory in the build dir and let it store the argfile there, that is annoying, because Cargo could invoke multiple rustc instances in parallel.

Let's keep it, but it makes me a bit grouchy 😆

Kobzol · 2026-06-21T08:36:37Z

+/// NOTE: In most scenarios we want to avoid arg files as it makes debugging more complicated
+///       so we try to avoid it if the command is not close the the OS limit.
+#[derive(Debug)]
+pub(crate) struct ArgFileCommand {


This is probably the tenth command abstraction we have in this repo, and now also duplicated in two places 😆 Could you please use the same trick we use in the shared_helpers in bootstrap to remove this copy paste?

Put ArgFileCommand into src/build_helper/arg_file_command.rs. Put a comment on top of it that says it has to be a self-contained file.

Use the ArgFileCommand in build_helper from bootstrap and compiletest normally

In bootstrap's shared_helpers.rs, manually include the arg_file_command.rs file via a #[path] mod (or include!, but I think that the former is better), so that the bootstrap rustc.rs binaries can use it.

sure, that a good idea. It hurt a bit having to duplicate it.

I used the #[path] approach like you mentioned in de3fd29 and d7a58fa

This allows compiletest to support the new Cargo `build-dir` layout which passes more `-L` flags as the `deps` dir has been split per build unit. This can be an issue on Windows as the max command size is fairly small.

This reduces the size of PATH on windows during macro expansion to avoid hitting windows limits. With the new Cargo build-dir layout this becomes more important as Cargo now passes more `-L` args which end up bloating PATH.

ranger-ross · 2026-06-21T09:57:00Z

I wonder if we should add some path placeholders to rustc, so that you could say something like --placeholder=FOO=/very/long/path -L[FOO]/d/e -L[FOO]/d/e

I think this makes a lot of sense. It'd help reduce command length.
The big downside of the new build-dir layout is that we need to pass all of the out dirs to rustc explictly.
I think upsides of the new build-dir layout still make it worth it, but I think we should try to eventually optimimize the length args sent to rustc.

Kobzol · 2026-06-21T10:55:39Z

Let's try!

@bors r=bjorn3,kobzol

rust-bors · 2026-06-21T10:55:42Z

📌 Commit 61f3e08 has been approved by bjorn3,kobzol

It is now in the queue for this repository.

rustbot assigned bjorn3 Apr 17, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Apr 17, 2026

ranger-ross mentioned this pull request Apr 17, 2026

Stabilize build-dir layout v2 rust-lang/cargo#16807

Open

3 tasks

bjorn3 reviewed Apr 17, 2026

View reviewed changes

Comment thread src/bootstrap/src/core/build_steps/compile.rs Outdated

weihanglo reviewed Apr 17, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

ranger-ross force-pushed the cargo-new-build-dir-layout branch from bf07fb8 to eae2cbf Compare April 17, 2026 15:27

ranger-ross commented Apr 17, 2026

View reviewed changes

This comment was marked as outdated.

Sign in to view

ranger-ross force-pushed the cargo-new-build-dir-layout branch from eae2cbf to ad47c85 Compare April 27, 2026 15:15

rustbot added A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue. labels Apr 27, 2026

This comment has been minimized.

Sign in to view

ranger-ross changed the title ~~Enable Cargo's new build-dir layout in boostrap~~ Enable Cargo's new build-dir layout Apr 27, 2026

RalfJung reviewed Apr 27, 2026

View reviewed changes

Comment thread src/tools/miri/test-cargo-miri/run-test.py Outdated

RalfJung reviewed Apr 27, 2026

View reviewed changes

Comment thread src/tools/compiletest/src/runtest/run_make.rs Outdated

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 27, 2026

bjorn3 reviewed Apr 27, 2026

View reviewed changes

Comment thread compiler/rustc_codegen_cranelift/build_system/build_sysroot.rs

ytmimi reviewed Apr 27, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

chore: Move CI to use Cargo's v2 layout (rustfmt)

6df137e

This also syncs `RUSTFLAGS: -D warnings` which is added in rust-lang/rustfmt

This comment has been minimized.

Sign in to view

Kobzol reviewed Jun 21, 2026

View reviewed changes

ranger-ross added 3 commits June 21, 2026 18:44

fix: Use arg files in bootstrap rustc and rustdoc

de3fd29

fix: Use arg files in compiletest

d7a58fa

This allows compiletest to support the new Cargo `build-dir` layout which passes more `-L` flags as the `deps` dir has been split per build unit. This can be an issue on Windows as the max command size is fairly small.

Kobzol reviewed Jun 21, 2026

View reviewed changes

Comment thread src/tools/compiletest/src/util.rs

This was referenced Jun 21, 2026

Rollup of 3 pull requests #158209

Closed

Rollup of 4 pull requests #158212

Merged

	/// This implementation is based off the of `ProcessBuilder` implementation in Cargo
	/// This implementation is based off the `ProcessBuilder` implementation in Cargo

	/// so we try to avoid it if the command is not close the the OS limit.
	/// so we try to avoid it if the command is not close to the OS limit.

Uh oh!

Conversation

ranger-ross commented Apr 17, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

weihanglo Apr 17, 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!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

ranger-ross Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ranger-ross commented Apr 19, 2026

Uh oh!

mati865 commented Apr 19, 2026

Uh oh!

ranger-ross commented Apr 19, 2026

Uh oh!

weihanglo commented Apr 19, 2026

Uh oh!

ranger-ross commented Apr 20, 2026

Uh oh!

This comment was marked as outdated.

rustbot commented Apr 27, 2026

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

ranger-ross commented Apr 27, 2026

Uh oh!

Uh oh!

ytmimi Apr 27, 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ytmimi Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

rustbot commented Jun 19, 2026

Uh oh!

ranger-ross commented Jun 19, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 19, 2026

Uh oh!

ranger-ross commented Jun 19, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 19, 2026

Uh oh!

This comment has been minimized.

ranger-ross commented Jun 20, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Jun 20, 2026

Uh oh!

ranger-ross commented Jun 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bjorn3 commented Jun 20, 2026

Uh oh!

ranger-ross commented Jun 20, 2026

Uh oh!

ranger-ross commented Apr 17, 2026 •

edited by rustbot

Loading

weihanglo Apr 17, 2026 •

edited by rustbot

Loading

ranger-ross Apr 17, 2026 •

edited

Loading

ytmimi Apr 27, 2026 •

edited by rustbot

Loading

ytmimi Apr 29, 2026 •

edited

Loading

ranger-ross commented Jun 20, 2026 •

edited

Loading

ranger-ross commented Jun 20, 2026 •

edited

Loading

Kobzol left a comment •

edited by rustbot

Loading

ranger-ross Jun 21, 2026 •

edited

Loading