Make RUSTC_BOOTSTRAP read the crate name from CARGO_CRATE_NAME

[Zalathar]

Background: In addition to the fixed values 1 and -1, RUSTC_BOOTSTRAP also accepts a comma-separated list of crate names, and only force-enables unstable functionality if the current crate name is in that list.

This is not actually used for bootstrapping the compiler. Instead, it exists so that when cargo sees a third-party crate trying to set RUSTC_BOOTSTRAP in build.rs, cargo can suggest a somewhat less horrifying alternative. See #77802 for more context.

---

The current implementation works by requiring every stable/nightly check to also pass an optional crate name, which is obtained by scanning &getopts::Matches for the --crate-name option. This creates extra mess and complexity at every call site, just for this one niche use-case, and doesn't even work for crate names that have been set in some other way.

---

As long as per-crate RUSTC_BOOTSTRAP exists, there is no truly satisfactory way to implement it. However, we can encapsulate some of the mess by getting the crate name from CARGO_CRATE_NAME, instead of getting it from the command-line.

This is a cargo-specific hack, but I think that's acceptable. We're dealing with RUSTC_BOOTSTRAP, which is already well outside the boundaries of what's “supported”, so what's important is that the cargo use-case that motivated this mess in the first place continues to work. And if someone out there is using RUSTC_BOOTSTRAP with a non-cargo build system, it's likely that their build system will let them set it to 1 on a per-crate basis anyway.

[rustbot]

r? @compiler-errors

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

[Zalathar]

Ideally we would just remove the per-crate thing entirely, but that would require coordination with cargo, and I suspect we might not get away with removing it anyway.

EDIT: As I suspected, full removal seems unlikely at this time.

[Noratrieb]

does this require coordination with cargo? the migration path is trivial: just go to setting 1 instead. sure, this is worse for stability, but I don't think we are gaining that much from doing it per crate.

(except..., arguably using RUSTC_BOOTSTRAP=crate is actually superior to using the nightly toolchain, since it allows you to limit whose nightly features you use, though that's more of a problem with the nightly toolchain.)

[Zalathar]

Cargo currently has an error message (for setting RUSTC_BOOTSTRAP in build.rs) that specifically mentions the possibility of setting RUSTC_BOOTSTRAP=crate-name:

https://github.com/rust-lang/cargo/blob/866eafef48f01bd32948bbd35839a573b11de64a/src/cargo/core/compiler/custom_build.rs#L991-L997

So it seems a bit rude to unilaterally make that not work.

(Granted, we're already in the extremely weird twilight zone of “supporting” the most explicitly unsupported feature of the compiler, so it's hard to even reason about what is or isn't OK.)

[jyn514]

please do not remove per-crate nightly overrides. the whole point of that was to allow banning RUSTC_BOOTSTRAP in build scripts, bringing that mess back is not worth making the code slightly cleaner.

i don’t have strong opinions on using CARGO_CRATE_NAME instead of —crate-name but there are people using RUSTC_BOOTSTRAP per-crate without cargo and this will break them. cc @glandium

[jyn514]

oh note also that this will break crates with dashes in their cargo package, so the cargo message will have to be updated anyway.

[Noratrieb]

this does definitely not bring back using rustc bootstrap in build.rs?

[glandium]

i don’t have strong opinions on using CARGO_CRATE_NAME instead of —crate-name but there are people using RUSTC_BOOTSTRAP per-crate without cargo and this will break them. cc @glandium

I can't attest to people using RUSTC_BOOTSTRAP per-crate without cargo. Firefox is using RUSTC_BOOTSTRAP per-crate with cargo.

[Zalathar]

oh note also that this will break crates with dashes in their cargo package, so the cargo message will have to be updated anyway.

This is handled by normalizing both CARGO_CRATE_NAME and RUSTC_BOOTSTRAP with .replace('-', "_").

[jyn514]

that is not correct. cargo package names need not be related in any way to crate names (and i think this can happen in practice with patch.crates.io)

[Zalathar]

that is not correct. cargo package names need not be related in any way to crate names (and i think this can happen in practice with patch.crates.io)

Well now I'm confused. If rustc is checking the crate name before this change, and continues to check the crate name afterwards, then I don't understand how the package name enters the picture.

(Is cargo actually printing the package name in its message, and getting away with it because they're usually the same?)

[Zalathar]

Closing this for now.

I'd like to do some kind of cleanup here, but it's not clear whether this PR is the way to go, and I'd prefer to spend my energy on other things.