feat(build-dir): Reorganize build-dir layout #15947

ranger-ross · 2025-09-10T14:06:03Z

What does this PR try to resolve?

This PR re-organizes the build-dir file layout structure to a layout organized by "build unit" when -Zbuild-dir-new-layout is enabled.
See #15010 for the motivations and design discussions.

Below is file structure generated for a foo crate with a single dependency on syn.

$ tree -a target
target
├── CACHEDIR.TAG
├── debug
│   ├── .cargo-lock
│   ├── examples
│   ├── foo
│   └── foo.d
├── .rustc_info.json
└── x86_64-unknown-linux-gnu
    ├── CACHEDIR.TAG
    └── debug
        ├── build
        │   ├── foo
        │   │   └── b34af33bc08ff01a
        │   │       ├── deps
        │   │       │   ├── foo-b34af33bc08ff01a
        │   │       │   └── foo-b34af33bc08ff01a.d
        │   │       └── fingerprint
        │   │           ├── bin-foo
        │   │           ├── bin-foo.json
        │   │           ├── dep-bin-foo
        │   │           └── invoked.timestamp
        │   ├── proc-macro2
        │   │   ├── 19da90e5dc4d123a
        │   │   │   ├── build-script
        │   │   │   │   ├── build-script-build
        │   │   │   │   ├── build_script_build-19da90e5dc4d123a
        │   │   │   │   └── build_script_build-19da90e5dc4d123a.d
        │   │   │   ├── deps
        │   │   │   └── fingerprint
        │   │   │       ├── build-script-build-script-build
        │   │   │       ├── build-script-build-script-build.json
        │   │   │       ├── dep-build-script-build-script-build
        │   │   │       └── invoked.timestamp
        │   │   ├── 1f78113122177c98
        │   │   │   ├── build-script-execution
        │   │   │   │   ├── invoked.timestamp
        │   │   │   │   ├── out
        │   │   │   │   ├── output
        │   │   │   │   ├── root-output
        │   │   │   │   └── stderr
        │   │   │   ├── deps
        │   │   │   └── fingerprint
        │   │   │       ├── run-build-script-build-script-build
        │   │   │       └── run-build-script-build-script-build.json
        │   │   └── aeb97a75f4852fa4
        │   │       ├── deps
        │   │       │   ├── libproc_macro2-aeb97a75f4852fa4.rlib
        │   │       │   ├── libproc_macro2-aeb97a75f4852fa4.rmeta
        │   │       │   └── proc_macro2-aeb97a75f4852fa4.d
        │   │       └── fingerprint
        │   │           ├── dep-lib-proc_macro2
        │   │           ├── invoked.timestamp
        │   │           ├── lib-proc_macro2
        │   │           └── lib-proc_macro2.json
        │   ├── quote
        │   │   ├── 2320198b748a1f4f
        │   │   │   ├── deps
        │   │   │   │   ├── libquote-2320198b748a1f4f.rlib
        │   │   │   │   ├── libquote-2320198b748a1f4f.rmeta
        │   │   │   │   └── quote-2320198b748a1f4f.d
        │   │   │   └── fingerprint
        │   │   │       ├── dep-lib-quote
        │   │   │       ├── invoked.timestamp
        │   │   │       ├── lib-quote
        │   │   │       └── lib-quote.json
        │   │   ├── c8338f34ba8c1b50
        │   │   │   ├── build-script
        │   │   │   │   ├── build-script-build
        │   │   │   │   ├── build_script_build-c8338f34ba8c1b50
        │   │   │   │   └── build_script_build-c8338f34ba8c1b50.d
        │   │   │   ├── deps
        │   │   │   └── fingerprint
        │   │   │       ├── build-script-build-script-build
        │   │   │       ├── build-script-build-script-build.json
        │   │   │       ├── dep-build-script-build-script-build
        │   │   │       └── invoked.timestamp
        │   │   └── ea48286d84faa854
        │   │       ├── build-script-execution
        │   │       │   ├── invoked.timestamp
        │   │       │   ├── out
        │   │       │   ├── output
        │   │       │   ├── root-output
        │   │       │   └── stderr
        │   │       ├── deps
        │   │       └── fingerprint
        │   │           ├── run-build-script-build-script-build
        │   │           └── run-build-script-build-script-build.json
        │   ├── syn
        │   │   └── af22844434ababc3
        │   │       ├── deps
        │   │       │   ├── libsyn-af22844434ababc3.rlib
        │   │       │   ├── libsyn-af22844434ababc3.rmeta
        │   │       │   └── syn-af22844434ababc3.d
        │   │       └── fingerprint
        │   │           ├── dep-lib-syn
        │   │           ├── invoked.timestamp
        │   │           ├── lib-syn
        │   │           └── lib-syn.json
        │   └── unicode-ident
        │       └── 0e4c1973d9247794
        │           ├── deps
        │           │   ├── libunicode_ident-0e4c1973d9247794.rlib
        │           │   ├── libunicode_ident-0e4c1973d9247794.rmeta
        │           │   └── unicode_ident-0e4c1973d9247794.d
        │           └── fingerprint
        │               ├── dep-lib-unicode_ident
        │               ├── invoked.timestamp
        │               ├── lib-unicode_ident
        │               └── lib-unicode_ident.json
        ├── .cargo-lock
        ├── examples
        └── incremental
            └── foo-1pb4z03k0sfwy
                ├── s-hbqsh9wq4l-036gz8p-1ykwn2aez3800vfccxoi5v4da
                │   ├── 3q86uityjlege824v7azpr1xa.o
                │   ├── 431tgb5yye2yse238oghx7ibf.o
                │   ├── 5lgaigp3xrviu0w7fzwe9es3i.o
                │   ├── 7vj2n3jygz04ai1js2r9pgco0.o
                │   ├── b3pykd7hm1idcuq6fo0gbe6vy.o
                │   ├── ddmxljz96gkbnnezdrmmxcogj.o
                │   ├── dep-graph.bin
                │   ├── query-cache.bin
                │   └── work-products.bin
                └── s-hbqsh9wq4l-036gz8p.lock

48 directories, 77 files

How to test and review this PR?

This PR still needs to be more thoroughly tested. Thus far I have been testing on simple test crates.
Also see #15874 for potential test harness improvements that could be used by this PR.

Follow up actions

Remove redundant -Cextra-filename in files where possible.

weihanglo · 2025-09-10T14:32:09Z

src/cargo/core/compiler/build_runner/compilation_files.rs

+    }
+
+    /// Directory where incremental output for the given unit should go.
+    pub fn incremental_dir(&self, unit: &Unit) -> PathBuf {


Just raise the awareness that this PR changed the incremental directory as well. See the relevant discussion: #15010 (comment).

We'll need to investigate the impact of this, or whether incremental compilation is still working.

#t-compiler > Cargo switching to one `-C incremental` directory per crate

Just opened a discussion on Zulip.

This is not a blocker BTW, as we are still experimenting.

We got a quick answer from Mark-Simulacrum. So no issue on loading incremental artifacts side.

simulacrum: AFAIK, rustc always loads incremental artifacts out of the directory only for the local crate - cross-crate state is always from rmeta

Weihang Lo: Ah nice. So it shouldn't be an issue, and Cargo doesn't need to add flock there because it already has one, right?

simulacrum: That sounds right to me.

Thinking about this more, I think we should probably start off conservatively and only have one incremental/, like today (which may run into problems with #4282). We can experiment with it later as changing it should have little impact.

The incremental directory takes up a significant chunk of the build-dir size. If we make it unique by -Cextra-filename then we will end up with multiple of them in the build, ballooning the build-dir size.

Its unclear what the performance impact would be. Having a single directory while changing inputs to -Cextra-filename could mean faster rebuilds if it can reuse a lot. Or it throws out a lot and thrashes the caches and is benefited by unique incremental/s.

For CI, its also a benefit to make it easy to clear to keep caching in CI easier.

Thanks, I think this sounds reasonable.
I was worried about a shared incremental being a point of lock contention when we introduce fine grain locking.

But thinking about a bit more, cargo only enables incremental for workspace and path crates so generally only a small subset would need to lock on this directory.
Also since build-dir internals are not public interface, we can change it in the future if we find another approach to be optimal

I have update the implementation to return to a single incremental/ directory.
See the updated PR description for the file layout.

epage · 2025-09-10T18:09:47Z

CC @Kobzol due to your work on rust-lang/rust#145408. If reducing duplicate search paths speeds up builds, I wonder what the impact will be of having more but pin point focused search paths will be.

weihanglo · 2025-09-10T21:18:43Z

If reducing duplicate search paths speeds up builds, I wonder what the impact will be of having more but pin point focused search paths will be.

Probably doesn't matter much because you still need to go through all of them to find what a crate need?

Edit: doesn't matter for primary crate, but for dependencies at the very root (like syn), it would be helpful.

epage · 2025-09-10T21:47:05Z

Probably doesn't matter much because you still need to go through all of them to find what a crate need?

Currently, the search path includes each -Cextra-filename variant of a package's build. With this change, it will only see the variants relevant for this build.

Kobzol · 2025-09-10T22:16:54Z

I would be a bit worried about perf. in large scenarios (e.g. 1000 crates, which is not that uncommon), as I suspect that rustc does a bunch of linear (hopefully not quadratic) searches through these directories and files in them. I would suggest benchmarking on https://github.com/zed-industries/zed 😆

weihanglo · 2025-09-10T23:08:46Z

Basically files under a search directory are preloaded and sorted and then binary search on them, so shouldn't be too bad? It may incur more opendir/readdir syscall though.

Like epage mentioned, it also help for transitive dependency loading less files.

But yeah worth some benchmark for larger projects.

Kobzol · 2025-09-11T10:46:53Z

Ah, I forgot that we do binary search already. In that case it will be probably fine, yeah.

Kobzol · 2025-09-11T15:38:06Z

I tried it on Zed and didn't see any perf. difference vs master, neither for clean builds nor for incremental rebuilds.

epage · 2025-09-11T15:46:35Z

I tried it on Zed and didn't see any perf. difference vs master, neither for clean builds nor for incremental rebuilds.

If there is a different, it will most likely appear if you have multiple unique versions for each package, e.g. from

cargo check
cargo clippy
cargo build
cargo doc
changing RUSTFLAGS
changing features

Kobzol · 2025-09-11T16:25:54Z

I didn't see the rebuild time getting higher for Zed when I added multiple versions from different cargo invocations.

epage · 2025-09-17T14:17:27Z

src/cargo/core/compiler/layout.rs

target/x86_64-unknown-linux-gnu/debug/build/proc-macro2-ee66340aaf816e44

So while this reduces the "max content per directory" (since proc-macro2-ee66340aaf816e44 will be a dir, rather than multiple files), we also have more flexibility for handling this.

Should we change from proc-macro2-ee66340aaf816e44 to proc/-macro2/ee66340aaf816e44?

Should we change from proc-macro2-ee66340aaf816e44 to proc/-macro2/ee66340aaf816e44?

Could we expand a bit more on the benefit of the proposed change?

There can be performance issues on Windows when a directory has a lot of content. We do this prefix-directory stuff for the index and for the build-dir workspace hash. This would be extending it to the build units within the package dir.

As Ross brought up, we don't have guidance on how big is big, what the growth will look like, etc

If we share this layout with the shared cache, then it will likely be more important.

I spent some time getting up to speed on Windows path issues. (goodness, its a deep rabbit hole)

As far as I can tell the main issue is Windows has much more restrictive path length than linux. (see #9770)
As for "too many files in a directory", I could not find much information on this.
Only a stack overflow post from 15 yrs ago saying "its well known that windows has poor performance on directories with many files".

That said I also found an article that claims a flat structure is better on ext4 for linux.
Granted the number of files in that article is huge and we would probably never have a build cache that gets that big.

Given the long paths issue on windows, perhaps it would be better to shorten names to help mitigate this? build-script-execution while descriptive is pretty long.

As far as I can tell, these are separate conversations, so I moved path lengths over to https://github.com/rust-lang/cargo/pull/15947/files#r2402207606

Sounds good.

As for the original suggestion

Should we change from proc-macro2-ee66340aaf816e44 to proc/-macro2/ee66340aaf816e44?

I lean towards not splitting these up. It keeps things simple and its questionable if there is even a performance issue in the first place.

As this is unspecified, we at least ahve the freedom to change it over time.

I think we should at minimum do <pkg-name>/<hash> as that would greatly simplify cargo clean -p <pkg-name>

I think that is a good idea 👍

The code for cargo clean -p is a bit hard to follow and I think with the new layout we have the opportunity to make the code simpler.

Made this change in the latest push.

epage · 2025-09-17T14:36:53Z

As a follow up to this PR, we may want to remove -Cextra-filename where possible since uniqueness is now guaranteed by the directory. Unsure if rustc relies on this for loading of rlibs or if we can only drop the hash from non-rlibs.

epage · 2025-09-17T14:40:11Z

Another reason we might want to remove -Cextra-filename where possible is to reduce the risk of hitting windows path length issues

epage · 2025-09-18T12:51:28Z

src/cargo/core/compiler/build_runner/compilation_files.rs

We'll need a test for cargo clean -p foo. Haven't looked at how thats implemented but might at least be a reason for name/hash rather than name-hash

I added a test for this in 0c143b1.
And good thing to because I silently broke that when I changed from name-hash to name/hash

weihanglo · 2025-10-03T13:17:55Z

We got this pretty frequently these days.

---- package::reserved_windows_name stdout ----
running `D:\a\cargo\cargo\target\debug\cargo.exe package`

thread 'package::reserved_windows_name' (8372) panicked at tests\testsuite\package.rs:2997:10:

test failed running `D:\a\cargo\cargo\target\debug\cargo.exe package`
error: process exited with code 0 (expected 101)
--- stdout

--- stderr
warning: manifest has no documentation, homepage or repository.
See https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata for more info.
   Packaging foo v0.0.1 (D:\a\cargo\cargo\target\tmp\cit\t2560\foo)
    Updating `dummy-registry` index
    Packaged 4 files, 1.4KiB (877B compressed)
   Verifying foo v0.0.1 (D:\a\cargo\cargo\target\tmp\cit\t2560\foo)
 Downloading crates ...
  Downloaded bar v1.0.0 (registry `dummy-registry`)
   Compiling bar v1.0.0
   Compiling foo v0.0.1 (D:\a\cargo\cargo\target\tmp\cit\t2560\foo\target\package\foo-0.0.1)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.55s

Re-running jobs.

epage · 2025-10-03T14:40:36Z

tests/testsuite/build_dir.rs

+[ROOT]/foo/build-dir/[HOST_TARGET]/CACHEDIR.TAG
+[ROOT]/foo/build-dir/[HOST_TARGET]/debug/.cargo-lock
+[ROOT]/foo/build-dir/[HOST_TARGET]/debug/build/foo-[HASH]/deps/foo[..][EXE]
+[ROOT]/foo/build-dir/[HOST_TARGET]/debug/build/foo-[HASH]/deps/foo[..].d
+[ROOT]/foo/build-dir/[HOST_TARGET]/debug/build/foo-[HASH]/fingerprint/bin-foo
+[ROOT]/foo/build-dir/[HOST_TARGET]/debug/build/foo-[HASH]/fingerprint/bin-foo.json
+[ROOT]/foo/build-dir/[HOST_TARGET]/debug/build/foo-[HASH]/fingerprint/dep-bin-foo
+[ROOT]/foo/build-dir/[HOST_TARGET]/debug/build/foo-[HASH]/fingerprint/invoked.timestamp


From @ranger-ross at #15947 (comment)

I spent some time getting up to speed on Windows path issues. (goodness, its a deep rabbit hole)

...

Given the long paths issue on windows, perhaps it would be better to shorten names to help mitigate this? build-script-execution while descriptive is pretty long.

There might be things we can do now but I think we should leave this partially for the stabilization process. In particular, if we can get #4282 to work out, we can likely drop <platform>/<profile>.

We could then also explore other things like how we store fingerprints and if that could be simplified in a way that reduces that controbuting to path lengths.

rustbot · 2025-10-05T08:04:30Z

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

ranger-ross · 2025-10-05T08:13:56Z

I am going to mark this PR as ready to review now.

I have addressed some of the preliminary feedback and update the PR description with a list of follow up tasks after this PR.
I added the -Cextra-filename as a follow up task given this PR is already getting a bit large and I think more discussion might be needed to determine what is safe to remove the hash from. (Though happy to include that in this PR if y'all'd prefer)

I did some basic sanity testing by verifying some popular projects build correctly with the new layout (tokio, clap, ripgrep).

src/cargo/core/compiler/layout.rs

src/cargo/core/compiler/mod.rs

tests/testsuite/build_dir.rs

epage · 2025-10-06T15:49:59Z

src/cargo/ops/cargo_clean.rs

    let (pkg_set, resolve) = ops::resolve_ws(ws, dry_run)?;
    let prof_dir_name = profiles.get_dir_name();
-    let host_layout = Layout::new(ws, None, &prof_dir_name)?;
+    let host_target = CompileTarget::new(target_data.short_name(&CompileKind::Host))?;


I'm surprised by how much was changed here.

I would have assumed we could do:

if new_layout { // rm all } else { // use the existing old logic }

What is it I'm missing?

sorry, I probably should have called this out in the PR description.

When -Znew-build-dir-layout is enabled, cargo clean -p clean packages in BOTH the new and old layout.
My thinking was that we could have support for both layouts for a few releases and eventually drop support for cleaning the old layout.

I can probably simplify this a bit if you think that is unnecessary.

Personally, I would err on the side of simplifying and us adding as needed.

This PR mixes the following in the same commit

new subdirectories

new parent directories

special cargo clean transitional logic

which makes things harder to track and consider. Doing it incrementally also allows us to better consider "do we need to bother?", especially if we can wait for feedback.

epage · 2025-10-06T15:52:48Z

src/cargo/core/compiler/layout.rs

        ws: &Workspace<'_>,
        target: Option<CompileTarget>,
        dest: &str,
+        is_host_layout: bool,


bools are always a precarious thing in parameter lists because their meaning is unclear. When the functions are local, its not too bad.

Making an enum would likely be too much boilerplate.

Options

Maybe we hold off on the adjusting the host layout until later, further reducing the scope of this change. Like I said, I wonder if we can get rid of some of our directory nesting which, depending on what we do, could make this short lived anyways.

Always have the caller create a variable for the bool and pass that in

this bool is only used for to know if we should omit the platform in path. (build-dir/debug vs build-dir/x86_64-unknown-linux-gnu /debug)
For the new layout, build-dir will never omit the platform.

One idea i have is to split Layout into ArtifactDirLayout and BuildDirLayout in a follow up PR.
I believe that would simply things (or at least separate the concerns) including this constructor fn.

What are your thoughts on not adding the platform to the directory unconditionally, at least at this phase? I feel like that is a source of some extra complication in this change, making it harder to understand and its a change for a directory that is not user visible, limiting the benefits.

…nner directories

ranger-ross · 2025-10-07T15:39:04Z

tests/testsuite/build_dir.rs

-[ROOT]/foo/build-dir/debug/.fingerprint/foo-[HASH]/invoked.timestamp
-[ROOT]/foo/build-dir/debug/deps/foo[..][EXE]
-[ROOT]/foo/build-dir/debug/deps/foo[..].d
+[ROOT]/foo/build-dir/[HOST_TARGET]/CACHEDIR.TAG


I believe this is a bug. CACHEDIR.TAG should not be affected by these changes.

Will look into this later this week.

epage · 2025-10-07T18:33:58Z

src/cargo/core/compiler/layout.rs

    }
    /// Fetch the deps path.
-    pub fn deps(&self) -> &Path {
+    pub fn deps(&self, _pkg_dir: &str) -> PathBuf {


While I was interested in things like incremental being created, taking in additional parameters that are unused I feel make this change harder to understand and likely would make the follow up harder to understand

epage · 2025-10-07T18:34:43Z

src/cargo/core/compiler/build_runner/mod.rs

            self.compilation
                .deps_output
-                .insert(kind, layout.deps().to_path_buf());
+                .insert(kind, layout.legacy_deps().to_path_buf());


Why is this legacy_deps?

In a follow up change, this is in an else for if build_dir_new_lay, so it seems like deps() would also work

epage · 2025-10-07T18:40:58Z

src/cargo/core/compiler/build_runner/compilation_files.rs

        assert!(self.metas.contains_key(unit));
        assert!(unit.artifact.is_true());
-        let dir = self.pkg_dir(unit);
+        let dir = self.pkg_dir(unit, "-");


This seems to be the only case for "-" separator

Being in deps, this looks internal

This is for artifact dependencies which is unstable

For myself, I'd prefer separate pkg_dir functions if we do need this. Being a parameter gives it the appearance of more flexibility than should be exercised in both value and runtime setting it

epage · 2025-10-07T18:44:28Z

src/cargo/core/compiler/layout.rs

+    pub fn fingerprint(&self, pkg_dir: &str) -> PathBuf {
+        self.fingerprint.join(pkg_dir)


Is this correct for us to be joining pkg_dir to self.fingerprint?

epage · 2025-10-07T18:45:17Z

src/cargo/core/compiler/layout.rs

+    pub fn fingerprint(&self, pkg_dir: &str) -> PathBuf {
+        self.fingerprint.join(pkg_dir)
+    }
+    /// Fetch the fingerprint path. (old layout)
+    pub fn legacy_fingerprint(&self) -> &Path {
        &self.fingerprint
    }


If we keep the legacy splits, I feel like this commit should have the existing functions delegate to the legacy ones. Then the follow up commit will call the legacy functions in the else branch. This would make the relationship more explicit and avoid questions like 8603e30#r2411571494

epage · 2025-10-07T18:46:56Z

src/cargo/core/compiler/mod.rs

+    if build_runner.bcx.gctx.cli_unstable().build_dir_new_layout {
+        let mut map = BTreeMap::new();
+
+        // Recursively add all depenendency args to rustc process
+        add_dep_arg(&mut map, build_runner, unit);
+
+        let paths = map.into_iter().map(|(_, path)| path).sorted_unstable();
+
+        for path in paths {
+            cmd.arg("-L").arg(&{
+                let mut deps = OsString::from("dependency=");
+                deps.push(path);
+                deps
+            });
+        }
+    } else {
+        cmd.arg("-L").arg(&{
+            let mut deps = OsString::from("dependency=");
+            deps.push(build_runner.files().deps_dir(unit));
+            deps
+        });
+    }


Something for us to keep in mind is that this change will likely lead to complaints similar to #13941.

src/cargo/core/compiler/mod.rs

rustbot added A-build-execution Area: anything dealing with executing the compiler A-layout Area: target output directory layout, naming, and organization Command-clean labels Sep 10, 2025

weihanglo reviewed Sep 10, 2025

View reviewed changes

This comment was marked as off-topic.

Sign in to view

Kobzol added a commit to Kobzol/rust that referenced this pull request Sep 11, 2025

Test perf of rust-lang/cargo#15947

b5e0064

ranger-ross force-pushed the impl-build-dir-layout branch from 854b259 to 2355753 Compare September 12, 2025 13:55

epage reviewed Sep 17, 2025

View reviewed changes

epage mentioned this pull request Sep 17, 2025

Added better filesystem layout testing harness #15874

Merged

epage reviewed Sep 18, 2025

View reviewed changes

ranger-ross force-pushed the impl-build-dir-layout branch from 2355753 to 47e0ec9 Compare September 30, 2025 13:46

This comment has been minimized.

Sign in to view

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

epage reviewed Oct 3, 2025

View reviewed changes

ranger-ross mentioned this pull request Oct 3, 2025

Support Cargo build-dir taiki-e/cargo-llvm-cov#452

Merged

chore: Added new HASH redaction for hashes in paths

9121077

ranger-ross force-pushed the impl-build-dir-layout branch from 47e0ec9 to b137a08 Compare October 4, 2025 04:28

rustbot added the A-testing-cargo-itself Area: cargo's tests label Oct 4, 2025

weihanglo mentioned this pull request Oct 4, 2025

package::reserved_windows_name test seems to be flaky recently #16047

Open

ranger-ross added 2 commits October 5, 2025 13:34

test(build-dir): Added cargo clean -p test

0c143b1

chore(build-dir): Forked build_dir.rs tests

0b81b44

ranger-ross force-pushed the impl-build-dir-layout branch from b137a08 to 030ddce Compare October 5, 2025 07:21

ranger-ross marked this pull request as ready for review October 5, 2025 08:04

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 5, 2025

rustbot assigned weihanglo Oct 5, 2025

ranger-ross mentioned this pull request Oct 6, 2025

Rework Cargo Build Dir Layout rust-lang/rust-project-goals#401

Open

2 tasks

epage reviewed Oct 6, 2025

View reviewed changes

src/cargo/core/compiler/layout.rs Show resolved Hide resolved

epage reviewed Oct 6, 2025

View reviewed changes

src/cargo/core/compiler/mod.rs Outdated Show resolved Hide resolved

epage reviewed Oct 6, 2025

View reviewed changes

src/cargo/core/compiler/mod.rs Show resolved Hide resolved

epage reviewed Oct 6, 2025

View reviewed changes

tests/testsuite/build_dir.rs Outdated Show resolved Hide resolved

epage reviewed Oct 6, 2025

View reviewed changes

tests/testsuite/build_dir.rs Show resolved Hide resolved

epage reviewed Oct 6, 2025

View reviewed changes

ranger-ross added 2 commits October 7, 2025 23:57

refactor(layout): Created dedicated layout helper fns for build-dir i…

8603e30

…nner directories

feat(build-dir): Reorganize build-dir layout

c849440

ranger-ross force-pushed the impl-build-dir-layout branch from 030ddce to c849440 Compare October 7, 2025 15:35

ranger-ross commented Oct 7, 2025

View reviewed changes

epage reviewed Oct 7, 2025

View reviewed changes

src/cargo/core/compiler/mod.rs Show resolved Hide resolved

		pub fn fingerprint(&self, pkg_dir: &str) -> PathBuf {
		self.fingerprint.join(pkg_dir)

feat(build-dir): Reorganize build-dir layout #15947

Are you sure you want to change the base?

feat(build-dir): Reorganize build-dir layout #15947

Conversation

ranger-ross commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR try to resolve?

How to test and review this PR?

Follow up actions

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage commented Sep 10, 2025

Uh oh!

weihanglo commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

epage commented Sep 10, 2025

Uh oh!

Kobzol commented Sep 10, 2025

Uh oh!

This comment was marked as off-topic.

weihanglo commented Sep 10, 2025

Uh oh!

Kobzol commented Sep 11, 2025

Uh oh!

Kobzol commented Sep 11, 2025

Uh oh!

epage commented Sep 11, 2025

Uh oh!

Kobzol commented Sep 11, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

epage Sep 17, 2025 • 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!

ranger-ross Oct 3, 2025 • 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!

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!

epage commented Sep 17, 2025

Uh oh!

epage commented Sep 17, 2025

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.

weihanglo commented Oct 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ranger-ross commented Sep 10, 2025 •

edited

Loading

weihanglo commented Sep 10, 2025 •

edited

Loading

epage Sep 17, 2025 •

edited

Loading

ranger-ross Oct 3, 2025 •

edited

Loading