Skip to content

Enable Cargo's new build-dir layout#155439

Open
ranger-ross wants to merge 7 commits into
rust-lang:mainfrom
ranger-ross:cargo-new-build-dir-layout
Open

Enable Cargo's new build-dir layout#155439
ranger-ross wants to merge 7 commits into
rust-lang:mainfrom
ranger-ross:cargo-new-build-dir-layout

Conversation

@ranger-ross

@ranger-ross ranger-ross commented Apr 17, 2026

Copy link
Copy Markdown
Member

View all comments

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?

Tracked in: rust-lang/cargo#15010

r? @bjorn3

cc: @epage

@rustbot 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
Comment thread src/bootstrap/src/core/build_steps/compile.rs Outdated
// 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.

@weihanglo weihanglo Apr 17, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

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.

@rust-log-analyzer

This comment has been minimized.

@ranger-ross ranger-ross force-pushed the cargo-new-build-dir-layout branch from bf07fb8 to eae2cbf Compare April 17, 2026 15:27
//
// 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);

@ranger-ross ranger-ross Apr 17, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Member Author

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

mati865 commented Apr 19, 2026

Copy link
Copy Markdown
Member

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

@ranger-ross

Copy link
Copy Markdown
Member Author

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

Copy link
Copy Markdown
Member

@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

Copy link
Copy Markdown
Member Author

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... 😅

@ranger-ross

This comment was marked as outdated.

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

rustbot commented Apr 27, 2026

Copy link
Copy Markdown
Collaborator

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

@rustbot 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
@rustbot

This comment has been minimized.

@ranger-ross ranger-ross changed the title Enable Cargo's new build-dir layout in boostrap Enable Cargo's new build-dir layout Apr 27, 2026
Comment thread src/tools/miri/test-cargo-miri/run-test.py Outdated
Comment thread src/tools/compiletest/src/runtest/run_make.rs Outdated
@ranger-ross

Copy link
Copy Markdown
Member Author

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

@rustbot 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
Comment thread compiler/rustc_codegen_cranelift/build_system/build_sysroot.rs
Comment thread src/tools/rustfmt/src/test/mod.rs Outdated
Comment on lines +1080 to +1086
// Chop off `deps`.
// Chop off `out`.
me.pop();
// Chop off `<hash>`.
me.pop();
// Chop off `<pkgname>`.
me.pop();
// Chop off `build`.

@ytmimi ytmimi Apr 27, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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

View changes since the review

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

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

@ytmimi ytmimi Apr 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

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.

@rust-bors

This comment has been minimized.

@rust-bors

rust-bors Bot commented Jun 13, 2026

Copy link
Copy Markdown
Contributor

💔 Test for 8e04c17 failed: CI. Failed job:

@rust-log-analyzer

This comment has been minimized.

@rustbot

rustbot commented Jun 15, 2026

Copy link
Copy Markdown
Collaborator

Some changes occurred in src/tools/cargo

cc @ehuss

@rustbot

This comment has been minimized.

@ranger-ross

Copy link
Copy Markdown
Member Author

Added some extra logging to Cargo to get an idea of what is happening.

@bors try jobs=x86_64-msvc-ext1

@rust-bors

This comment has been minimized.

rust-bors Bot pushed a commit that referenced this pull request Jun 15, 2026
Enable Cargo's new build-dir layout


try-job: x86_64-msvc-ext1
@rust-bors

rust-bors Bot commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

💔 Test for 385b483 failed: CI. Failed job:

@rust-log-analyzer

This comment has been minimized.

@ranger-ross

Copy link
Copy Markdown
Member Author

@bors try jobs=x86_64-msvc-ext1

@rust-bors

This comment has been minimized.

@rust-bors

rust-bors Bot commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

💔 Test for 9f3aa86 failed: CI. Failed job:

@rust-log-analyzer

This comment has been minimized.

@rust-bors

This comment has been minimized.

This also syncs `RUSTFLAGS: -D warnings` which is added in
rust-lang/rustfmt
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.
@rustbot

rustbot commented Jun 19, 2026

Copy link
Copy Markdown
Collaborator

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

Copy link
Copy Markdown
Member Author

@bors try jobs=x86_64-msvc-ext1

@rust-bors

This comment has been minimized.

@rust-bors

rust-bors Bot commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

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

@ranger-ross

Copy link
Copy Markdown
Member Author

@bors try jobs=x86_64-msvc-1

@rust-bors

This comment has been minimized.

@rust-bors

rust-bors Bot commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

💔 Test for e07d099 failed: CI. Failed job:

@rust-log-analyzer

Copy link
Copy Markdown
Collaborator

The job x86_64-msvc-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[RUSTC-TIMING] similar test:false 3.919
[RUSTC-TIMING] tidy test:true 8.844
[RUSTC-TIMING] tidy test:false 18.166
    Finished `release` profile [optimized] target(s) in 1m 37s
     Running unittests src\lib.rs (build\x86_64-pc-windows-msvc\bootstrap-tools\x86_64-pc-windows-msvc\release\build\tidy/3846a9382910394a\out\tidy-3846a9382910394a.exe)

running 34 tests
test alphabetical::tests::bless_multiline ... ok
test alphabetical::tests::bless_funny_numbers ... ok
test alphabetical::tests::bless_smoke ... ok
---
[TIMING:end] test::RustdocJSStd { build_compiler: Compiler { stage: 2, host: x86_64-pc-windows-msvc, forced_compiler: false }, target: x86_64-pc-windows-msvc } -- 60.330
[TIMING:start] test::RustdocJSNotStd { target: x86_64-pc-windows-msvc, compiler: Compiler { stage: 2, host: x86_64-pc-windows-msvc, forced_compiler: false } }
[TIMING:start] test::Compiletest { test_compiler: Compiler { stage: 2, host: x86_64-pc-windows-msvc, forced_compiler: false }, target: x86_64-pc-windows-msvc, mode: rustdoc-js, suite: "rustdoc-js", path: "tests/rustdoc-js", compare_mode: None }
##[group]Testing stage2 with compiletest suite=rustdoc-js mode=rustdoc-js (x86_64-pc-windows-msvc)
FATAL: failed to run "D:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\bin\\rustc.exe" "-Cdebuginfo=0" "--print=all-target-specs-json" "-Zunstable-options"
--- stdout

--- stderr


thread 'main' (1108) panicked at src\tools\compiletest\src\common.rs:1207:9:
fatal error
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Bootstrap failed while executing `test --stage 2 --skip=compiler --skip=src`
Build completed unsuccessfully in 2:16:41
make: *** [Makefile:115: ci-msvc-py] Error 1
  local time: Fri Jun 19 19:09:38 CUT 2026
  network time: Fri, 19 Jun 2026 19:09:38 GMT
##[error]Process completed with exit code 2.
##[group]Run echo "disk usage:"
echo "disk usage:"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-CI Area: Our Github Actions CI A-compiletest Area: The compiletest test runner A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-rustfmt Relevant to the rustfmt team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.