Forbid setting RUSTC_BOOTSTRAP from build scripts

[nox]

rust-lang/packed_simd#205

[rust-highfive]

r? @ehuss

(rust_highfive has picked a reviewer for you, use r? to override)

[hsivonen]

It doesn't seem productive to introduce a change whose purpose is to deliberately break a pattern that a production user of Rust (in this case Firefox) uses to make things work.

Note that your change would most likely have the opposite effect of what you want: Right now, using build.rs to unlock nightly features on a per-crate basis prevents accidental dependencies on nightly-only features from other crates. If you force the Firefox build system to blanket-enable nightly-only features, any crate in Firefox will be able to accidentally develop a dependency on a nightly-only feature.

CC @glandium.

[nox]

The effect that I want is that I don't want crates to stop building for weird reasons such as circumventing the entire stable/unstable mechanism. This patch prevents that.

[SimonSapin]

It’s hard to imagine how a #![feature(foo)] attribute could be added to a crate accidentally.

[skade]

@hsivonen The entire point of the RUSTC_BOOTSTRAP variable is to serve as a big gate to not use this in production. If crate-granular opt-in to nightly were a desirable feature, there'd be a flag for that.

Especially the engineering org that produces huge parts of Rust should take great care not to spearhead hacks against the language ecosystem, which this essentially is :(.

With some effort, I could definitely see cargo/rustc diagnostics that collects used #![feature(foo)] flags from a build for comparison to a whitelist.

[hsivonen]

It’s hard to imagine how a #![feature(foo)] attribute could be added to a crate accidentally.

Compare this search with this search.

With some effort, I could definitely see cargo/rustc diagnostics that collects used #![feature(foo)] flags from a build for comparison to a whitelist.

I encourage considering this from the perspective of what's practical (regressing Firefox performance by disabling portable SIMD or not letting Firefox adopt features like allocator and OOM customization on the schedule Firefox needed them is not practical) and not from the perspective of whether the Firefox build system does something that contradicts how things are supposed to work.

Realistically, the alternative to the build.rs approach is to one way or another have the Firefox build system run with nightly features enabled for all crates. I don't see how that would be an improvement.

[SimonSapin]

This build.rs script might be preferable to Firefox (if RUSTC_BOOTSTRAP is to be used one way or another), but I think such a build script should not be published on crates.io, especially if it is unconditional like this. A crate that uses unstable features should not silently "just work" on the stable channel without some kind of opt-in from its users.

Could the mozilla-central repository have a patched version of packed_simd, so that rust-lang/packed_simd#205 doesn’t need to land upstream?

[hsivonen]

Could the mozilla-central repository have a patched version of packed_simd, so that rust-lang/packed_simd#205 doesn’t need to land upstream?

It's a possibility, but I thought it would have been impolite to just fork packed_simd without proposing the patch upstream first.

[glandium]

With my Firefox build system peer hat, the whole point of the hack is to avoid setting RUSTC_BOOTSTRAP globally, which we were doing in the past! And that's worse than a few crates doing it explicitly, because /any/ crate can start requiring nightly features without anything being noticed (and IIRC that has happened when we did set RUSTC_BOOTSTRAP globally). And we clearly don't want to require nightly rust to build Firefox.

With my Rust developer hat on, I have used this hack in some crates (boxext and allocator_api ; although both don't need it anymore). I don't think cargo should actively prevent people who want to do the extra work of supporting stable crates on top of unstable rust features. And I don't think that should be forbidden on crates.io either. Or if that is, following the same logic, crates that only work on nightly rust should be forbidden too.

[Mark-Simulacrum]

I agree that making this change seems like a step backwards rather than forwards, even though I would love to see no downstream users (especially as large as Firefox) using RUSTC_BOOTSTRAP.

There's really nothing we can do, and perhaps nothing we even want to do, that would entirely remove this from something people can do. As such, making it as easy as possible to limit it in scope to as few crates as possible seems like something we should encourage rather than discourage.

Speaking from a personal level, publishing such inherently unstable crates on crates.io feels quite a bit worse than using this from within build systems (e.g., rustbuild, whatever Firefox has...). I'm not sure how to quantify this or nail it down though -- I'm not sure what my distinction is exactly.

[skade]

Compare this search with this search.

I'm confused here. The left side is vastly dominated by #![feature(test)] in benchers (which searchfox doesn't categorize as such). Still, I'd expect an org that cares about this to keep this page manageable. This seems like a rather easy to check list.

I'm not convinced.

I encourage considering this from the perspective of what's practical (regressing Firefox performance by disabling portable SIMD or not letting Firefox adopt features like allocator and OOM customization on the schedule Firefox needed them is not practical) and not from the perspective of whether the Firefox build system does something that contradicts how things are supposed to work.

I don't find it practical to take a sledgehammer to a system that people have spent years to build and argue for the sledgehammer. Appeals to pragmatism are fine, but I'd also like to appeal the damage this example does.

Realistically, the alternative to the build.rs approach is to one way or another have the Firefox build system run with nightly features enabled for all crates. I don't see how that would be an improvement.

There is a realistic alternative to set the compiler to bootstrapping mode build system wide, at the cost of slightly more tooling to vet the dependencies. I see your pain, and I'd be totally willing to argue fast-tracking improvements for your use-case, but this option isn't it.

@glandium With my Rust team hat, I'm pretty angry at this behaviour and I think it should actually be banned from crates.io. It leads to de-facto stabilisation, which the whole system around having features on nightly only is built to avoid. The lid is on the cookie jar for a reason.

If people want to do this locally in their code tree, fine.

I'm quite saddened that we now discuss the validity of this, as it's obviously a terrible hack around systems that were put in place for a reason.

[nox]

It is no crate’s business to subvert the stable channel into being the nightly one and then cause compilation failures for people on the stable channel, if I’m using nightly I expect some breakage, if I’m using stable I’m surely not expecting things to break. That this is even a discussion is frankly disappointing to me. Make an in-tree fork of the dependency in which you want to put this horrible hack in. Make a tool to audit which unstable features are used in which crates. The crate ecosystem should not be corrupted just because the Firefox build system doesn’t want to do otherwise.

…

-- Anthony Ramine

Le 29 janv. 2019 à 01:58, Mike Hommey ***@***.***> a écrit : With my Firefox build system peer hat, the whole point of the hack is to avoid setting RUSTC_BOOTSTRAP globally, which we were doing in the past! And that's worse than a few crates doing it explicitly, because /any/ crate can start requiring nightly features without anything being noticed. And we clearly don't want to require nightly rust to build Firefox. With my Rust developer hat on, I have used this hack in some crates (boxext and allocator_api ; although both don't need it anymore). I don't think cargo should actively prevent people who want to do the extra work of supporting stable crates on top of unstable rust features. And I don't think that should be forbidden on crates.io either. Or if that is, following the same logic, crates that only work on nightly rust should be forbidden too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[glandium]

Random "stable" crates on crates.io break, that's a matter of fact. Some have even broken with stable rust updates. That's rare but that happens. Others have broken because of semver problems and other subtleties. There are also breaks when a crate uses new stable rust features. Those are theoretically less of a problem because you can update your rust compiler, but they do happen (and no, you can't always update your rust compiler).

That's just one different way things can break, and my promise when I use this hack in published crates is that semver-compatible versions will fix the problem for newer stable versions of rust.

[SimonSapin]

“Stability without stagnation” is a big part of the messaging around the Rust language. We tell people that if they are on the Stable release channel, they can (mostly) count on upgrading up to every 6 weeks being relatively painless.

At the same time, we have a mechanism for experimenting with implementation of features that are not ready yet. It should be assumed that any unstable feature will break eventually. If betting on them staying unchanged starts being a widespread practice, we lose the point of separating them from stable features in the first place. So reliance of unstable features must require some form of deliberate opt-in, which comes with responsibility to deal with inevitable breakage.

With crates.io, the maintainers of a library and the maintainers of an application that uses (possibly indirectly) that library can be different sets of people. It’s important that both of them deliberately opt into instability. Usually the former do so with #![feature(…)] an the latter by using a Nightly compiler. Firefox maintainers chose to use RUSTC_BOOTSTRAP instead of Nightly, but this is still a deliberate opt-in that makes them responsible to deal with breakage.

By publishing println!("cargo:rustc-env=RUSTC_BOOTSTRAP=1"); on crates.io, you are removing this opt-in from application that (indirectly) depend on that crate. They might start relying on unstable features without being aware of it at all. This breaks the language’s stability promise.

It might or might not be the place of tooling to try to technically prevent this, but I think it should be considered socially unacceptable. This is a Tragedy of the commons waiting to happen.

[skade]

@glandium That's all fine, but the project has set up RUSTC_BOOTSTRAP for a reason (it's for bootstrapping, and for bootstrapping only). Using it in your build tooling is already sketchy, but at least local to your project. I can empathise with that. What you are doing is a dangerous boundary play around the rules we have set up on the public crate host, setting a dangerous example.

Those rules are for users to keep things predictable and non-confusing. You're only adding to the confusion. People compiling with stable expect that nightly features are not available. OUR promise is something different.

[glandium]

FWIW, a github search for cargo:rustc-env=RUSTC_BOOTSTRAP=1 yields, if you exclude all Firefox forks: encoding_rs and simd, already discussed here, and https://github.com/strake/i-o.rs. Only for simd and that i-o.rs is it not behind a feature gate.

[mati865]

Cargo shouldn't prevent users from doing whatever they way in their local crates although it could warn with something like: "RUSTC_BOOTSTRAP is unsupported for usages other than compiler bootstraping, you are on your own now".

Crates.io definitely should forbid publishing crates with RUSTC_BOOTSTRAP (or other dangerous variables) set unconditionally or by default features. Ideally it should be forbidden when hidden behind feature as well but enforcing it before maintainers can fix their crates would cause even more issues than it solves and there is the case of Firefox using it as lesser evil.

[hsivonen]

So there are three issues here:

1. Is it reasonable for Firefox to use RUSTC_BOOTSTRAP?
2. Should cargo prevent setting RUSTC_BOOTSTRAP from build.rs?
3. If not, should crates that use it from build.rs be on crates.io?

For the first item:

That's all fine, but the project has set up RUSTC_BOOTSTRAP for a reason (it's for bootstrapping, and for bootstrapping only).

Clearly, it was created for bootstrapping only, but practical experience from a notable production user of Rust has lead to the identification of a non-bootstrapping use case that it also addresses.

A real-world major production user of Rust uses non-nightly compiler builds because 1) those have gone through the process of shaking out short-lived bugs that you might encounter in if you picked an arbitrary nightly build of the compiler and 2) the product is also built with Linux/BSD distros' in-archive compilers also and it's already enough of a departure from distro culture to effectively require them to make rustc and cargo rolling-release packages, so asking them to package a nightly compiler snapshot for Firefox seems even less workable.

Yet, there are use cases for using nightly features in Firefox in specific cases:

1. The simd crate case of there being a long-running mismatch between Rust stabilization priorities and Firefox shipping needs. (When Rust has an awesome better-than-C++ feature for writing faster software, it doesn't seem like a persuasive position that Firefox should refrain from using such feature, and not for a couple of weeks but for years.)
2. Even if the SIMD situation didn't exist, the situation encountered by @glandium that Firefox for a relative short time (on the order of a couple of Rust release trains) needs to use a Rust feature before it makes it through the Rust trains can arise at any time, and it's not reasonable to have to change the whole toolchain to an arbitrarily-picked nightly toolchain snapshot (remember Linux/BSD distros, too) in such a case.

So I think unlocking nightly features in a stable toolchain for non-bootstrapping purposes have practical use cases, and making things harder in practice for those facing these use cases because the use cases are not supposed to exist in theory would be entirely counterproductive.

For the second item:

In practice, unlocking nightly features on a per-crate basis instead of unlocking them for all crates helps minimize unintended casual proliferation of dependencies on nightly-only features. I can see how the solution is theoretically repulsive, but I suggest it's bad to double down on theory if the expectable practical consequences run counter to the goal of the theory.

While these are Open Source tools and there isn't outright DRM preventing me from patching the tools and using them to address use cases that I have (although there is the issue of Linux/BSD distros having to also patch the tools if they are to use the tools to build something that needs the modifications to the tools in order to build), I'm unhappy about tools deliberately refusing to work for the person trying to operate them when practical use cases don't conform to the theory of the tools.

In that sense, I hope this PR is rejected, but I'm much more committed to the first item than this second item, so I could live with Firefox going back to blanket RUSTC_BOOTSTRAP=1 for all crates if the Cargo team wishes to take away crate-level granularity.

at the cost of slightly more tooling to vet the dependencies.

I don't think it's reasonable to expect the burden of writing such tools to be on the users for whom cargo without this PR addresses the present use cases.

As far as writing new tooling code goes, the ability to unlock nightly features declaratively for specific crates in the dependency graph from a top-level Cargo.toml would be a much more productive and use case-acknowledging approach to all this that this PR.

For the third item:

It might or might not be the place of tooling to try to technically prevent this, but I think it should be considered socially unacceptable.

I'm sympathetic to the notion that RUSTC_BOOTSTRAP=1 from build.rs shouldn't appear on crates.io, and I was hesitant to accept the PRs to add it to encoding_rs and simd.

However, it's worthwhile to observe that just accepting the PRs for the trunk of these crates and publishing on crates.io was the easiest path and why that is so:

cargo-vendor makes it deliberately hard to locally modify the vendored crates. Initially, requests to make it easier to modify them (i.e. engage in activities explicitly permitted and envisioned by Open Source licensing) were met with pushback of the "you are not supposed to do that" kind. Eventually, cargo-edit-locally happened, but something that one might expect to be a matter of running cargo vendor followed by an application of a patch still takes more ceremony.

I see parallels here: An opinionated tool taking the "you are not supposed to do that" position. And in this case, the easiest way to get work done in the context of that "you are not supposed to do that" opinionated tool position is to upload Firefox peculiarities to crates.io so that you only need to run cargo vendor and you're done.

Now, do you double down on embodying "you are not supposed to do that" in tools or address use cases faced by production users of the tool? (I this case, AFAICT, being able to unlock nightly features for a particular crate in the dependency graph from within the top-level Cargo.toml would be the best practical solution that I can come up with. But until that exists, landing this PR does not seem like a productive thing to do.)

[dwijnand]

How does rustbuild avoid being affect by this?

[petrochenkov]

@dwijnand
Rustbuild sets RUSTC_BOOTSTRAP=1 globally, without per-crate granularity.

[skade]

@hsivonen I fundamentally don't agree with the notion you're trying to pass here, namely that the practical use is fine and the concerns are purely theoretical. Even local opt-in has lead to serious situations in many language communities ("I love Haskell, it's a PRAGMAtic language").

Yes, there's a philosophy behind the way Rust works there and this philosophy gives people very simple ways to work. This PR wouldn't be up if you didn't actually widen the scope of your RUSTC_BOOTSTRAP use and if you didn't actually publish your crate on crates.io. You've been caught doing it and now you are arguing that this has been sound all time. It's not like "keep our use of RUSTC_BOOTSTRAP local" couldn't also be framed as a question of philosophy.

Rust stable not allowing any use of nightly features is a feature of the language ecosystem. Yes, it brings pains, but these are to disable other, very real, and practical, pains.

cargo-vendor shouldn't factor in here, issues with that should be taken there. Yes, I appreciate you have a big project to manage, no, it's not like other people haven't.

It's not about opinionated or not. Rusts stability guarantee is architected around having "stable Rust only builds stable code" be a true statement. It's a fundamental cornerstone of our stability guarantee. I don't want to add another asterisk to it.

It's not "you are not supposed to do that", it's "this is potentially harzardous" and you are using a big project to push it.

FWIW: I'm also happy for working on practical solutions around that stalement, I just don't think the current path and action is feasible.

[oli-obk]

In practice, unlocking nightly features on a per-crate basis instead of unlocking them for all crates helps minimize unintended casual proliferation of dependencies on nightly-only features. I can see how the solution is theoretically repulsive, but I suggest it's bad to double down on theory if the expectable practical consequences run counter to the goal of the theory.

If that is the use-case, could we modify RUSTC_BOOTSTRAP to allow values beyond 0 and 1: a comma separated list of crate names where the compilation process is treated as RUSTC_BOOTSTRAP. As far as I can tell this solves all the desires discussed in this PR:

1. this PR is merged
2. RUSTC_BOOTSTRAP does not show up on crates.io anywhere
3. no single crate is allowed to circumvent stability
4. any project can choose to include nightly crates in their build system by explicitly opting into the breakage for just those specific crates
   • They were already able to do this via RUSTC_BOOTSTRAP=1 globally, so we don't lose anything

[hsivonen]

This PR wouldn't be up if you didn't actually widen the scope of your RUSTC_BOOTSTRAP use and if you didn't actually publish your crate on crates.io.

I'd be happier if there was an easier way for top-level compilation to control this on a per crate basis than having the code travel through crates.io. (To be clear: I don't think those build.rs files on crates.io is a good situation.)

a comma separated list of crate names where the compilation process is treated as RUSTC_BOOTSTRAP

Being able to set a list of crates that RUSTC_BOOTSTRAP applies to either from the top-level Cargo.toml or via a list in the value of the RUSTC_BOOTSTRAP environment variable would be great and much preferable to the build.rs trick.

[SimonSapin]

just accepting the PRs for the trunk of these crates and publishing on crates.io was the easiest path

Yes, cutting corner can be easier. That doesn’t make the negative consequences go away.

Maybe crates.io makes it easier to make code written for Firefox available to a Firefox build. In that context, go ahead and cut all the corners you want. You’re the one who will deal with the breakage later.

What’s problematic IMO is shipping this hack in a library that you publicize as fit for other projects to use, without your other users having necessarily opted into instability. This is where you’re hurting the ecosystem the most.

[hsivonen]

Yes, cutting corner can be easier. That doesn’t make the negative consequences go away.

As noted, the purpose of this change was to limit the negatives of blanket RUSTC_BOOTSTRAP and the reason why I didn't reject putting this in the upsteam crates is that cargo deliberately makes local changes more complicated than having mach drop the build.rs files in the right directories.

You are right, though, that having this in encoding_rs is a potential risk of negative consequences. (The simd crate has pretty clearly been on the verge of explicit obsoletion anyway.)

What’s problematic IMO is shipping this hack in a library that you publicize as fit for other projects to use, without your other users having necessarily opted into instability. This is where you’re hurting the ecosystem the most.

Whoa. That's a readme editing oversight. Sorry. I'll fix that as soon I'm on a computer that can push to GitHub.

[SimonSapin]

Hmm, do you mean that encoding_rs should not be outside of Firefox? What about rust-lang/packed_simd#205 ?

[gnzlbg]

I haven't closed @hsivonen PR in packed_simd because they raise a real problem that Firefox has and I am not sure I fully understand it or how to solve it.

IIUC using RUSTC_BOOTSTRAP for all crates in the dependency graph is too coarse grained, while adding RUSTC_BOOTSTRAP via the build.rs of particular crates is fine grained enough, but it comes with the problem that publishing those build.rs to crates.io is considered by (almost?) everybody to be a very bad idea, up to the point of this PR which proposes that this is something we should actively forbid.

The long term solution is for Firefox to stop passing any kind of RUSTC_BOOTSTRAP, either by moving to nightly Rust, or by only using stable Rust features. I don't think this feedback is actionable for them at the moment though, so we should consider offering a better temporary solution until they get there.

We could add a CARGO_RUSTC_BOOTSTRAP=$(crate),* environment variable to cargo, that would pass RUSTC_BOOTSTRAP to rustc only for the listed crates. This is better than both using RUSTC_BOOTSTRAP globally, and than adding RUSTC_BOOTSTRAP to the build.rs of crates published on crates.io.

I'll prefer to wait for such a workaround to be implemented, and for Firefox to migrate from using this hack on build.rs files towards a better solution, before we forbid it completely with this PR. But I agree that we should merge this PR eventually because doing this for crates in crates.io is just wrong.

[oli-obk]

I created a prototype impl in the compiler: https://github.com/rust-lang/rust/compare/master...oli-obk:hacky_mac_hackstrap?expand=1

I think we should indeed go with the cargo solution instead of a rustc solution, it seems like a cargo solution will be significantly simpler.

[hsivonen]

Hmm, do you mean that encoding_rs should not be outside of Firefox?

No, I mean the documentation should have made it clear that the simd-accel feature depends on nightly Rust features and opts out of compatibility guarantees with future releases of Rust. (After all, if SIMD acceleration could be provided with compatibility with future Rust releases, the wouldn't need to be a cargo feature opt-in.)

What about rust-lang/packed_simd#205 ?

It seems clear from the top of the readme that packed_simd you can expect even less compatibility with future compilers of packed_simd than you can expect of a typical nightly-only crate.

The long term solution is for Firefox to stop passing any kind of RUSTC_BOOTSTRAP, either by moving to nightly Rust, or by only using stable Rust features.

In the case of SIMD, my hope is that the long-term solution is that packed_simd (with into_bits) becomes std::simd on stable Rust.

As noted above, solving the SIMD case doesn't mean that the use case will go away. The allocator/OOM customization features were using nightly-only features for a couple or so of Rust release cycles. It seems reasonable to expect that similar cases will pop up from time to time in the future (hopefully unlike SIMD only for a couple of Rust release cycles each), so the use case of opting a crate into nightly-only features on non-nightly Rust will remain even if not continuously.

I created a prototype impl in the compiler

Thank you.

[glandium]

If we're going to have a way for cargo to do something per crate, I think it would be more interesting to have a completely generic way to pass arbitrary environment variables per-crate, which kind of overlaps with an idea I had yesterday to help with some problems with build flags and want to send a pre-RFC for, some time today or tomorrow.

[nikomatsakis]

We discussed this briefly in today's @rust-lang/core meeting, since it seemed like the questions being raised here go to the heart of Rust's stability story. We didn't decide ultimately whether to accept or not accept this PR. We plan to revisit this discussion in the meeting after the all hands (or perhaps a bit during all hands). (In particular, it'd be nice to find the "right team" to make the final call here.)

Some comments:

First, the decision not to allow crates to "encapsulate" the use of nightly features was definitely deliberate, and @nox is correct that using build.rs in this fashion effectively sidesteps that. The reasons were simple: we wanted people to know if they are (transitively) relying on nightly features, so that they are not unexpectedly broken by updates to those nightly features. (In this sense, there is a big difference between using RUST_BOOTSTRAP at the "top level" and allowing crates to be publishing on crates.io that use it selectively.)

We know that a careful crate author can issue point releases to fix those that kind of breakage, but of course not all crate authors are so careful and diligent. Moreover, it may happen that crate authors don't want to go back and issue point releases for ALL prior semver versions, since often people only maintain the most recent branch of a crate and so forth. This means that upgrading rustc may cause breakage for people who happen to be using older versions even if the crate author is diligent.

It is of course also true that, as @glandium notes, breakage can happen in other ways, such as bug fixes and the like. But such breakage is far less common than changes to nightly features, so there does seem to be a difference in kind.

One point raised was that we don't presently have a precedent for banning similar things in build.rs, so there may be some concern about opening that door.

I guess more generally there is the question of whether a large number of productive users are using RUST_BOOTSTRAP in practice -- if so, that does point to a problem that we ought to resolve, although perhaps the resolution is simply that we have to find the features in question and stabilize them.

[nrc]

Although the core team intends to discuss further, I think it is safe to close this PR for now - although we might well do something like this, I think we'd want to enforce this server-side on crates.io instead of/as well as in Cargo.

@nox thanks for the PR and for bringing the issue to our attention

[hsivonen]

I filed a feature request for addressing this use case in a way that doesn't involve baking application-specific configuration into general-interest crates.io crates.

[Centril]

I guess more generally there is the question of whether a large number of productive users are using RUST_BOOTSTRAP in practice -- if so, that does point to a problem that we ought to resolve, although perhaps the resolution is simply that we have to find the features in question and stabilize them.

I just want to note that, tho it is not the implication of what you are saying, with my language team hat on (but speaking only for myself...), I never want to find myself in a situation where I'm forced to OK the stabilization of a feature due to RUSTC_BOOTSTRAP rather than on the merits of the feature itself.

[gnzlbg]

@nikomatsakis

We plan to revisit this discussion in the meeting after the all hands (or perhaps a bit during all hands).

Was this discussed at the all hands?

I guess more generally there is the question of whether a large number of productive users are using RUST_BOOTSTRAP in practice -

Could we schedule a crater run that does not allow this gather some information about how many crates are doing this?

[sfackler]

I don't know if it came up elsewhere, but. I chatted with some people about this at the all hands.

1. There are definitely use cases in closed ecosystems to perform some magic to opt into unstable features. For example, we've turned on Cargo's equivalent to the bootstrap key in our internal build infrastructure to use alternative registries. However, it is deeply unacceptable for libraries in the crates.io ecosystem to pull this stunt.
2. We should make some changes to make this kind of thing harder or at least more explicitly frowned upon. For example, we could change RUSTC_BOOTSTRAP=1 to __RUSTC_INTERNAL_ONLY_BOOTSTRAPPING_MAGIC_DO_NOT_USE_UNLESS_YOU_ARE_A_PACKAGER="I am definitely bootstrapping the Rust 1.32.0 distribution". I wouldn't be opposed to this change to filter it out of build scripts, but it does seem a bit sad to give Cargo any knowledge of this feature at all.

[carols10cents]

Rather than commenting on a closed PR, please add your comments on the open feature request issue. Thanks!

[steveklabnik]

Not including this patch has now had wider ecosystem consequences: https://www.reddit.com/r/rust/comments/c8bgwf/ripgrep_dependency_has_been_marked_for/

I'm going to include a comment over on the feature request as well, but didn't want the consequence to get lost.