cargo icon indicating copy to clipboard operation
cargo copied to clipboard

`cargo clean -Zbuild-dir-new-layout -p foo` does not clean uplifted example depinfo files

Open epage opened this issue 1 month ago • 5 comments

Problem

#16300 mirrors some clean.rs tests into clean_new_layout but assert_all_clean fails on several tests because dep info files remain.

#16300 introduces support for removing uplifted files but the examples have a hash in them and so doesn't get removed.

For some reason, it looks like the non-upllifted content in the old build layout is what is deleting the uplifted dep info?

Steps

$ cargo new foo
$ cd foo
$ mkdir examples
$ echo "fn main() {}" > examples/foo.rs
$ cargo +nightly build -Zbuild-dir-new-layout
$ cargo clean -Zbuild-dir-new-layout -p foo
$ ls target/debug/examples

And see the dep info files still there

Or

Uncommit the assert_all_clean lines from clean_new_layout.rs and add the assert function in from clean.rs

Possible Solution(s)

No response

Notes

Conditionally add a glob for hashes based on the TargetKind

Version


epage avatar Nov 25 '25 20:11 epage

The new layout clean code only removes build_unit(&pkg.name()), but example files are stored in a separate build_dir().examples() directory with hashed filenames (e.g., foo-.d). The old layout handles this with glob patterns in cargo_clean.rs, but the new layout path is missing equivalent logic. IMO incremental compilation files (build_dir().incremental()) also need to be cleaned for the new layout.

charmitro avatar Nov 26 '25 20:11 charmitro

The new layout clean code only removes build_unit(&pkg.name()), but example files are stored in a separate build_dir().examples() directory with hashed filenames (e.g., foo-.d). The old layout handles this with glob patterns in cargo_clean.rs, but the new layout path is missing equivalent logic.

The reason I wanted to dig into this more is build_dir() is supposed to be all non-uplifted artifacts while artifact_dir() is for uplifted artifacts yet we have the non-uplifted code deleting uplifted files as far as I can tell.

IMO incremental compilation files (build_dir().incremental()) also need to be cleaned for the new layout.

Yes, I have that in my local change for this

epage avatar Nov 26 '25 21:11 epage

Also I have #16304 up which will cause conflicts with any changes for this

epage avatar Nov 26 '25 21:11 epage

What I'm further confused about is my own projects don't have hashes in the uplifted example names and I'm not seeing how to reproduce that.

epage avatar Nov 26 '25 22:11 epage

What I'm further confused about is my own projects don't have hashes in the uplifted example names and I'm not seeing how to reproduce that.

Yes, uplifted example names don't have hashes. If I'm not mistaken, the hashed files (ex-{hash}, ex-{hash}.d, ex.{hash}.rcgu.o) are rustc's raw output that exists alongside the uplifted files in the same directory.

$ cargo new foo
$ cd foo
$ mkdir examples
$ echo "fn main() {}" > examples/foo.rs
$ cargo +nightly build -Zbuild-dir-new-layout --example foo
$ cargo +nightly clean -Zbuild-dir-new-layout -p foo
$ ls target/debug/examples

charmitro avatar Dec 02 '25 23:12 charmitro

Those steps did not reproduce for me and rustc does not write to target/debug/examples, cargo copies things to that directory from others.

epage avatar Dec 03 '25 19:12 epage

Did some more debugging and it turns out it is intermediate build artifacts being placed there.

Setting

[build]
build-dir = "{cargo-cache-home}/build/{workspace-path-hash}"

will cause the files to no longer be there. Instead they will be in the build directory at that location.

If nothing else, we'll need to make sure the delete the hashed files out of the build dir and not the target dir. However, I think this warrants further investigation because it seems odd that we are copying these files out of the unit directories.

epage avatar Dec 03 '25 19:12 epage

#16335 is an alternative fix

epage avatar Dec 03 '25 20:12 epage