Skip to content

Conversation

epage
Copy link
Contributor

@epage epage commented Oct 15, 2025

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?

epage added 5 commits October 15, 2025 13:24
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 rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 15, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 15, 2025

r? @ehuss

rustbot has assigned @ehuss.
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

Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

The cargo team recently discussed this, and this was the outcome we agreed to.

I think the artifact name conflict seems fine for now. The error message doesn't seem so bad to me. If possible, the restriction can be lifted in the future.

@ehuss ehuss enabled auto-merge October 16, 2025 00:44
@epage epage force-pushed the restrict branch 4 times, most recently from af76550 to 9b23ede Compare October 16, 2025 20:55
@ehuss ehuss added this pull request to the merge queue Oct 16, 2025
Merged via the queue into rust-lang:master with commit 9d63ae2 Oct 16, 2025
25 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants