-
Notifications
You must be signed in to change notification settings - Fork 2.7k
fix(script): Tweak cargo script build-dir / target-dir #16086
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
r? @weihanglo rustbot has assigned @weihanglo. Use |
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.
f026ab3
to
9ece28b
Compare
weihanglo
approved these changes
Oct 14, 2025
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.
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 defaulttarget-dir
exclude allbuild-dir
content by putting the default cargo scripttarget-dir
underbuild-dir
.Cargo script target-dir precedence
target-dir
target-dir
"{cargo-cache-home}/target/{workspace-path-hash}"
"{build-dir}/target"
Cargo script build-dir precedence
build-dir
build-dir
target-dir
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 intarget-dir
despite being an intermediate build artifact, so this also moves that intobuild-dir
. This does mean that if someone has a sharedbuild-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
examples/
when its not usedtarget_dir == build_dir