Skip to content

perf(test): try putting tmp rustup installations in OS' tmp directory - #5212

Draft
rami3l wants to merge 2 commits into
rust-lang:mainfrom
rami3l:perf/test-tmp-dir
Draft

rami3l wants to merge 2 commits into
rust-lang:mainfrom
rami3l:perf/test-tmp-dir

Conversation

@rami3l

@rami3l rami3l commented Nov 13, 2026 •

Copy link
Copy Markdown
Member

Continuation of #5211:

Since the artifact directory is now hashed, I don't think it makes any more sense to store the temporary (mock) Rust installations alongside the artifacts. So I am thinking about maybe putting them into the OS' tmp dir instead, hoping to further reduce the size of ./target this way.

Status Quo

As stated above, the rustup test suite currently puts its temporary rustup installations under ./target/.

This is of course very convenient, but it also has a practical reason: each installation is directly derived from CARGO_BIN_EXE_rustup-init via hard links to that file, otherwise each test will have its own actual copy of rustup-init[EXE] which is, needless to say, unacceptable.

The key point here is that hard links are not allowed to go across devices, otherwise we'll hit the io::ErrorKind::CrossesDevices error and the whole test fixture will not work.

Proposed Solution

The proposed solution is in two parts:

The first part restores the part that has been broken by Rust v1.100.0 WRT the exe_test_dir() helper function. Before Rust v1.100, it used to return ./target or ./target/<tuple> (which we will call <base> from now on), but now it points to <base>/(debug|release)/build/rustup/<unit-hash>/. This means that shared states that existed in the past are now separated by unit hash. With this fix, it regains the ability to find the same old <base> and thus we are out of cargo's way.

The second part evaluates whether the OS' tmp dir <ostmp> can be used for testing, which is currently only possible without io::ErrorKind::CrossesDevices. To do so, it tries to create an empty "probe" directory under <base> and rename() it to <ostmp>/rustup-test. If this succeeds, that directory is used as the return value of exe_test_dir() instead of the original <base>. This way, we can have the OS manage the test temporaries for us.

@rustbot

This comment has been minimized.

@rami3l
rami3l force-pushed the perf/test-tmp-dir branch 2 times, most recently from f80987f to 0a7b6e1 Compare November 13, 2026 16:03
@rami3l rami3l changed the title perf(test): throw tmp rustup installations in OS' tmp directory perf(test): try putting tmp rustup installations in OS' tmp directory Nov 13, 2026
@rami3l
rami3l force-pushed the perf/test-tmp-dir branch 11 times, most recently from 15e2425 to fce7233 Compare November 13, 2026 20:54
Comment thread src/test.rs
Ok(exe_dir.parent().unwrap().to_owned())

let mut comps = curr_exe_dir.components().collect::<Vec<_>>();
let retained_comps = match &comps[..] {

@ChrisDenton ChrisDenton Nov 14, 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.

Can we do something that's less dependent on output directory layout? E.g. can we use CARGO_TARGET_TMPDIR or so?

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.

@ChrisDenton This is complicated, because neither CARGO_TARGET_TMPDIR nor CARGO_BIN_EXE_rustup-init is guaranteed to be set on both integration tests and unit tests, and this function is a common infrastructure of both sides, meaning if we need a fallback anyway on one side, it might just as well be the actual implementation :( Maybe you have a better idea?

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.

Well my better idea would be "maybe we should ask the cargo team" even if as a feature request. Because I know we aren't the only ones that need some scratch space for test infra.

But short of that, manually implementing it is fine. I just don't love it.

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants