fix(script): Remove name sanitiztion outside what is strictly required #16120
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
We discussed this in a recent Cargo team meeting: - Windows is moving away from this - The reserved name is irrespective of whether there is an extension, meaning that windows will limit whether the script can exist in the first place and we don't need further sanitization.
This was discussed in the cargo team meeting: - This is a `bin` and so what name is used to access it is of little importance - We don't sanitize other sysroot package names
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
added
the
S-waiting-on-review
39 tasks
ehuss
approved these changes
Oct 16, 2025
epage
force-pushed
the
restrict
branch
4 times, most recently
from
af76550 to
9b23ede
Compare
rustbot
removed
the
S-waiting-on-review
bors
added a commit
to rust-lang/rust
that referenced
this pull request
Oct 22, 2025
Update cargo submodule 7 commits in 367fd9f213750cd40317803dd0a5a3ce3f0c676d..344c4567c634a25837e3c3476aac08af84cf9203 2025-10-15 15:01:32 +0000 to 2025-10-21 21:29:43 +0000 - refactor: Centralize CONTEXT style (rust-lang/cargo#16135) - chore(triagebot): `A-json-output` for machine_message.rs (rust-lang/cargo#16133) - refactor: JSON message with less allocations (rust-lang/cargo#16130) - More warning conversions (rust-lang/cargo#16126) - fix(check): Fix suggested command for bin package (rust-lang/cargo#16127) - fix(script): Remove name sanitiztion outside what is strictly required (rust-lang/cargo#16120) - refactor: Centralize some more styling (rust-lang/cargo#16124) r? ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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?
Note that we are currently inconsistent in that
testgets sanitized but nothing else insysroot.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:
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?