Skip to content

Conversation

epage
Copy link
Contributor

@epage epage commented Oct 10, 2025

What does this PR try to resolve?

This is meant to unblock efforts for allowing cargo scripts to use artifact names like deps without being sanitized or erroring. This is done by making the default target-dir exclude all build-dir content by putting the default cargo script target-dir under build-dir.

Cargo script target-dir precedence

before after
explicit target-dir explicit target-dir
"{cargo-cache-home}/target/{workspace-path-hash}" "{build-dir}/target"

Cargo script build-dir precedence

before after
explicit build-dir explicit build-dir
explicit target-dir explicit target-dir
"{cargo-cache-home}/target/{workspace-path-hash}" "{cargo-cache-home}/target/{workspace-path-hash}"

In doing this split, it highlighted the fact that we still had Cargo.lock for cargo scripts in target-dir despite being an intermediate build artifact, so this also moves that into build-dir. This does mean that if someone has a shared build-dir between their projects, their scripts will get a bit confusing. I plan to highlight that in the tracking issue / stabilization report.

How to test and review this PR?

Notes

Work left to do for artifact names

  • Stop creating examples/ when its not used
  • Move the conflict check from parse time to build time
  • Make the conflict check dependent on if target_dir == build_dir

@rustbot rustbot added A-workspaces Area: workspaces S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 10, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 10, 2025

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

epage added 4 commits October 10, 2025 15:17
Kind of confusing to have them defined in terms of each other but
- When we move the defualt `build-dir`, I expect we'll just delete the
  conditional and make the cargo script default `build-dir` the only
  default `build-dir`
- I plan to change the cargo script default `target-dir`
This avoids needing to be careful about cargo scripts conflicting with
"artifact names".
Granted, there will be more work to deal with the validation checks but
that comes later.
@epage epage changed the title fix(ws): Tweak cargo script build-dir / target-dir fix(script): Tweak cargo script build-dir / target-dir Oct 10, 2025
@epage epage force-pushed the script-dir branch 4 times, most recently from f026ab3 to 9ece28b Compare October 14, 2025 15:51
@weihanglo weihanglo added this pull request to the merge queue Oct 14, 2025
Merged via the queue into rust-lang:master with commit 93ac6e1 Oct 14, 2025
25 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 14, 2025
@epage epage deleted the script-dir branch October 14, 2025 21:20
bors added a commit to rust-lang/rust that referenced this pull request Oct 15, 2025
Update cargo

17 commits in 81c3f77a467359c8be6bc747dc93ec66a6e4ce11..367fd9f213750cd40317803dd0a5a3ce3f0c676d
2025-10-10 18:41:02 +0000 to 2025-10-15 15:01:32 +0000
- test: Don't look for a specfic ANSI color (rust-lang/cargo#16118)
- docs(guide): Clarify where to set config (rust-lang/cargo#16107)
- test(rustfix): re-enable disabled test due to unused variables (rust-lang/cargo#16114)
- Convert the "manifest has no things" warning to annotate_snippets. (rust-lang/cargo#16113)
- doc: make it clearer that `target.<cfg>.linker` is supported (rust-lang/cargo#16112)
- docs(guide): Cover feature-unification (rust-lang/cargo#16108)
- fix(gctx): types are unsupported not unknown (rust-lang/cargo#16109)
- fix(script): Tweak cargo script build-dir / target-dir (rust-lang/cargo#16086)
- docs(gctx): explain Value deserialization step-by-step (rust-lang/cargo#16105)
- docs(guide): Talk about removing unused features (rust-lang/cargo#16085)
- test(config): exercise unsupported TOML types (rust-lang/cargo#16100)
- docs(gctx): a bit more of how config deserialization works (rust-lang/cargo#16094)
- Refactor `Layout` into `BuildDirLayout` and `ArtifactDirLayout` (rust-lang/cargo#16092)
- Add alternative linker to the build performance guide (rust-lang/cargo#15991)
- refactor(gctx): extract error to a module (rust-lang/cargo#16091)
- fix: Fixed nightly tests failing due to unused_variables lint (rust-lang/cargo#16098)
- fix(script): Store cargo script lockfiles in build-dir (rust-lang/cargo#16087)

r? ghost
epage added a commit to epage/cargo that referenced this pull request Oct 15, 2025
Making this an error now gives us the best compatibility story.
A user can workaround this by overriding `package.name`.
Our paths forward include:
- Leave it as-is or at least improve the error message for this case
- Make it so we don't need the error message
- Add back sanitizating the name

Ideally, we make it so we don't need the error message.
The ground work was laid out for this in rust-lang#16086.
The next step is to move the conflict error from manifest parsing to
compilation so we can check whether target-dir and build-dir overlap to
error.
There are unknowns with this,
including whether the usability is good enough for making this error
conditional on the target-dir and build-dir overlapping.
We may even want to wait until we change the default build-dir.
@rustbot rustbot added this to the 1.92.0 milestone Oct 15, 2025
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Oct 16, 2025
Update cargo

17 commits in 81c3f77a467359c8be6bc747dc93ec66a6e4ce11..367fd9f213750cd40317803dd0a5a3ce3f0c676d
2025-10-10 18:41:02 +0000 to 2025-10-15 15:01:32 +0000
- test: Don't look for a specfic ANSI color (rust-lang/cargo#16118)
- docs(guide): Clarify where to set config (rust-lang/cargo#16107)
- test(rustfix): re-enable disabled test due to unused variables (rust-lang/cargo#16114)
- Convert the "manifest has no things" warning to annotate_snippets. (rust-lang/cargo#16113)
- doc: make it clearer that `target.<cfg>.linker` is supported (rust-lang/cargo#16112)
- docs(guide): Cover feature-unification (rust-lang/cargo#16108)
- fix(gctx): types are unsupported not unknown (rust-lang/cargo#16109)
- fix(script): Tweak cargo script build-dir / target-dir (rust-lang/cargo#16086)
- docs(gctx): explain Value deserialization step-by-step (rust-lang/cargo#16105)
- docs(guide): Talk about removing unused features (rust-lang/cargo#16085)
- test(config): exercise unsupported TOML types (rust-lang/cargo#16100)
- docs(gctx): a bit more of how config deserialization works (rust-lang/cargo#16094)
- Refactor `Layout` into `BuildDirLayout` and `ArtifactDirLayout` (rust-lang/cargo#16092)
- Add alternative linker to the build performance guide (rust-lang/cargo#15991)
- refactor(gctx): extract error to a module (rust-lang/cargo#16091)
- fix: Fixed nightly tests failing due to unused_variables lint (rust-lang/cargo#16098)
- fix(script): Store cargo script lockfiles in build-dir (rust-lang/cargo#16087)

r? ghost
epage added a commit to epage/cargo that referenced this pull request Oct 16, 2025
Making this an error now gives us the best compatibility story.
A user can workaround this by overriding `package.name`.
Our paths forward include:
- Leave it as-is or at least improve the error message for this case
- Make it so we don't need the error message
- Add back sanitizating the name

Ideally, we make it so we don't need the error message.
The ground work was laid out for this in rust-lang#16086.
The next step is to move the conflict error from manifest parsing to
compilation so we can check whether target-dir and build-dir overlap to
error.
There are unknowns with this,
including whether the usability is good enough for making this error
conditional on the target-dir and build-dir overlapping.
We may even want to wait until we change the default build-dir.
epage added a commit to epage/cargo that referenced this pull request Oct 16, 2025
Making this an error now gives us the best compatibility story.
A user can workaround this by overriding `package.name`.
Our paths forward include:
- Leave it as-is or at least improve the error message for this case
- Make it so we don't need the error message
- Add back sanitizating the name

Ideally, we make it so we don't need the error message.
The ground work was laid out for this in rust-lang#16086.
The next step is to move the conflict error from manifest parsing to
compilation so we can check whether target-dir and build-dir overlap to
error.
There are unknowns with this,
including whether the usability is good enough for making this error
conditional on the target-dir and build-dir overlapping.
We may even want to wait until we change the default build-dir.
epage added a commit to epage/cargo that referenced this pull request Oct 16, 2025
Making this an error now gives us the best compatibility story.
A user can workaround this by overriding `package.name`.
Our paths forward include:
- Leave it as-is or at least improve the error message for this case
- Make it so we don't need the error message
- Add back sanitizating the name

Ideally, we make it so we don't need the error message.
The ground work was laid out for this in rust-lang#16086.
The next step is to move the conflict error from manifest parsing to
compilation so we can check whether target-dir and build-dir overlap to
error.
There are unknowns with this,
including whether the usability is good enough for making this error
conditional on the target-dir and build-dir overlapping.
We may even want to wait until we change the default build-dir.
epage added a commit to epage/cargo that referenced this pull request Oct 16, 2025
Making this an error now gives us the best compatibility story.
A user can workaround this by overriding `package.name`.
Our paths forward include:
- Leave it as-is or at least improve the error message for this case
- Make it so we don't need the error message
- Add back sanitizating the name

Ideally, we make it so we don't need the error message.
The ground work was laid out for this in rust-lang#16086.
The next step is to move the conflict error from manifest parsing to
compilation so we can check whether target-dir and build-dir overlap to
error.
There are unknowns with this,
including whether the usability is good enough for making this error
conditional on the target-dir and build-dir overlapping.
We may even want to wait until we change the default build-dir.
github-merge-queue bot pushed a commit that referenced this pull request Oct 16, 2025
#16120)

### What does this PR try to resolve?

Note that we are currently inconsistent in that `test` gets sanitized
but nothing else in `sysroot`.

We reviewed what gets sanitized in the Cargo team meeting and found none
of these really apply to cargo scripts except conflicting with artifact
dirs.

For conflicting with artifact dirs, making this an error now gives us
the best compatibility story.
A user can workaround this by overriding `package.name`.
Our paths forward include:
- Leave it as-is or at least improve the error message for this case
- Make it so we don't need the error message
- Add back sanitizating the name

Ideally, we make it so we don't need the error message.
The ground work was laid out for this in #16086.
The next step is to move the conflict error from manifest parsing to
compilation so we can check whether target-dir and build-dir overlap to
error.
There are unknowns with this,
including whether the usability is good enough for making this error
conditional on the target-dir and build-dir overlapping.
We may even want to wait until we change the default build-dir.

### How to test and review this PR?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-workspaces Area: workspaces

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants