allow overwriting the output of rustc --version

[oli-obk]

Our wonderful bisection folk have to work around crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for.

This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by

• choosing when to update rustc
• choosing when to update dependencies
• choosing which nightly features they are willing to take the breakage for

The reason this breakage occurs is that the build script of some crates run rustc --version, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency.

This PR (and the policy I want to establish with this FCP) is only for situations like the version_check's supports_feature function. It is explicitly not for autocfg or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too.

This PR allows changing the version and release strings reported by rustc --version via the RUSTC_OVERRIDE_VERSION_STRING env var. The bisection issue is then fixed by rust-lang/cargo-bisect-rustc#335.

I mainly want to establish a compiler team policy:

We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to.

Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection.

I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.

[rustbot]

r? @wesleywiser

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

[oli-obk]

@rfcbot merge

[rfcbot]

Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Aaron1011
• @cjgillot
• @compiler-errors
• @davidtwco
• @eddyb
• @estebank
• @jackh726
• @lcnr
• @matthewjasper
• @michaelwoerister
• @nagisa
• @oli-obk
• @petrochenkov
• @pnkfelix
• @wesleywiser

Concerns:

• subsequent-crates-io-policy resolved by allow overwriting the output of rustc --version #124339 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[wesleywiser]

I have a few concerns with this approach:

1. By linting on MIR build of the version_check::supports_feature, I believe this means we'll generate this lint anytime the crate is built even if the function isn't used. There are ways to use version_check correctly (such as using it to check if rustc's version is a specific stable release number and then enabling the use of language/libstd features stabilized in that release) so incorrectly linting on cases that are written correctly seems very bad.
   • We could instead lint on calls to version_check::supports_feature which would be resolve that particular issue and provide a lint span that is far more actionable than the current experience (most commonly "an indirect dependency depends on version_check but we won't tell you which one(s)").
2. For crate authors that really want to do this approach, I suspect they will simply copy the relevant parts out of version_check directly into their build.rs and then remove the dependency, nullifying the lint. As you mention, there are other crates as well that can be problematic when trying to perform bisections. I would rather see a more comprehensive solution that doesn't specifically target one crate in particular.
   • For instance, we could support a RUST_ANTI_BOOTSTRAP environment variable which would cause the compiler to report itself as a stable compiler and ignore the RUST_BOOTSTRAP environment variable. Perhaps more usefully, RUSTC_PRETEND_TO_BE="whatever rustc --version output you want here" would allow completely overriding the normal version output. cargo-bisect-rustc could then be taught to set these flags automatically for the user. Something like this would resolve the issue for a number of similar crates without singling any of them out.

[oli-obk]

We already have RUSTC_FORCE_RUSTC_VERSION. I have added a test for it and made cargo-bisect-rustc support it with just a flag: rust-lang/cargo-bisect-rustc#335

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[petrochenkov]

I read the description, but I still don't understand what is version_check::supports_feature, how it is related to the compiler, and what this PR does exactly.

[jackh726]

I'm a little...lost here. Digging around, if I understand correctly: ahash does feature detection to enable stdsimd on nightly, which was removed in recent nightlies. And because of that, there are crates that will no longer compile on the latest nightly (but will on the latest stable). In this case, this made finding a regression commit difficult.

The proposed policy in this FCP is to not just discourage this use but actively prevent it? That definitely seems a bit too far for me.

I think it definitely makes sense to treat the compilers as "stable" when bisecting - particularly because we don't have any guarantees of stability for nightly features.

I also think it might be worth thinking about why things like supports_feature exists and work to bring the language and compiler to a point that we can support to cases (and thus also have tight control on how this support changes for things like "pretending to be stable for bisecting").

(edit: seems like I was not the only one confused)

[estebank]

Adding a flag to tell rustc to behave as stable as the PR does now will close #123404.

---

It should help with a (sufficient?) subset of the problematic cases that the PR initially wanted to address.

There will be cases where the bisection will be for crates using nightly features and a combination of those cases + incorrect rust version checking will continue to manifest the problem of bisecting making crates like ahash incorrectly enabling nightly features that will fail at quasi-random places in the bisection.

---

+1 on landing RUSTC_FORCE_RUSTC_VERSION (maybe as RUSTC_FORCE_VERSION?), after updating the PR title/description.

[oli-obk]

I expanded the main PR description.

[oli-obk]

I also think it might be worth thinking about why things like supports_feature exists and work to bring the language and compiler to a point that we can support to cases (and thus also have tight control on how this support changes for things like "pretending to be stable for bisecting").

That has the opposite effect of what I'm proposing, as it endorses nightly detection. Nightly detection is absolutely incompatible with semver. It means that users testing their stable crate on nightly to be aware of upcoming changes get random failures from crates that work fine on stable.

[estebank]

I appreciate the desire by crate authors to make things "just work™️", but it would be much better for the build.rs scripts making feature detection to provide a uses visible message asking them to enable feature flags explicitly. This will have a much smaller chance of causing things going awry.

[chorman0773]

One thing I'd like is a way to say "Print whatever $RUST_VERSION the compiler is built for, but leave off nightly/dev/beta qualifiers". I've run into this with a number of projects, which will be a pain when I package various projects up in tarballs that shouldn't stop building (and shouldn't take on a defacto MxSRV) in the future because someone assumed that X nightly feature will exist forever.

[thomcc]

it would be much better for the build.rs scripts making feature detection to provide a uses visible message asking them to enable feature flags explicitly

You can't¹ actually do this, since cargo swallows the output from build scripts.

Footnotes

1. Okay, you can open /dev/tty or the equivalent on windows², but this has bad effects. ↩

2. $CONOUT or whatever, I don't remember. It's been long enough that I've forgotten the actual name. ↩

[chorman0773]

cargo doesn't swallow stderr IIRC.

[oli-obk]

@bors r=wesleywiser

[bors]

📌 Commit 44f63d6 has been approved by wesleywiser

It is now in the queue for this repository.

[matthiaskrgr]

@bors rollup=iffy

[bors]

⌛ Testing commit 44f63d6 with merge ca601f8...

[bors]

💔 Test failed - checks-actions

[oli-obk]

@bors r=wesleywiser

[bors]

📌 Commit 92f263b has been approved by wesleywiser

It is now in the queue for this repository.

[bors]

⌛ Testing commit 92f263b with merge 006c8df...

[bors]

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing 006c8df to master...

[rust-timer]

Finished benchmarking commit (006c8df): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -2.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.8%	[-2.8%, -2.8%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.8%	[-2.8%, -2.8%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 768.761s -> 769.469s (0.09%)
Artifact size: 331.87 MiB -> 331.90 MiB (0.01%)