Stream: t-compiler/major changes

Topic: Require users to confirm they know RUSTC_… compiler-team#350


Joshua Nelson (Aug 26 2020 at 20:16, on Zulip):

@Josh Triplett said:

(also, if we were to change it, we could also change the name of the environment variable to something more clear)

do you have a preferred name?

Joshua Nelson (Aug 26 2020 at 20:17, on Zulip):

maybe ALLOW_UNSTABLE_ON_STABLE?

Jake Goulding (Aug 26 2020 at 20:17, on Zulip):

I_OPT_OUT_OF_RUST_STABILITY_GUARANTEES_AND_CANNOT_COMPLAIN_ABOUT_IT

Lokathor (Aug 26 2020 at 20:17, on Zulip):

^

Joshua Nelson (Aug 26 2020 at 20:18, on Zulip):

in addition to the text you have to set it to? or instead of? it seems it's getting pretty long :laughing:

Lokathor (Aug 26 2020 at 20:18, on Zulip):

no you just set it to 42

Jake Goulding (Aug 26 2020 at 20:18, on Zulip):

I'd say set vs unset

Jake Goulding (Aug 26 2020 at 20:19, on Zulip):

but also I_OPT_OUT_OF_RUST_STABILITY_GUARANTEES=AND_CANNOT_COMPLAIN_ABOUT_IT is possible

Joshua Nelson (Aug 26 2020 at 20:19, on Zulip):

personally I like ALLOW_UNSTABLE_ON_STABLE="I understand that unstable features are unstable and may break at any time", but I'm ok with I_OPT_OUT_OF_RUST_STABILITY_GUARANTEES_AND_UNDERSTAND_UNSTABLE_FEATURES_ARE_UNSTABLE

Lokathor (Aug 26 2020 at 20:20, on Zulip):

I've named a crate feature unsafe_i_promise_to_not_run_this_on_the_wrong_platform

cuviper (Aug 26 2020 at 20:20, on Zulip):

This is cute and all, but is there really any problem currently, that justifies changing this?

Joshua Nelson (Aug 26 2020 at 20:21, on Zulip):

cuviper said:

This is cute and all, but is there really any problem currently, that justifies changing this?

yes, I ran into someone a couple weeks ago who tried to use this

Joshua Nelson (Aug 26 2020 at 20:21, on Zulip):

and just didn't understand why it was bad

Joshua Nelson (Aug 26 2020 at 20:21, on Zulip):

one sec, let me find a link

simulacrum (Aug 26 2020 at 20:21, on Zulip):

IMO making it super long and unwieldy is unhelpful

simulacrum (Aug 26 2020 at 20:21, on Zulip):

Calling it RUSTC_FORCE_UNSTABLE, though, seems fine

simulacrum (Aug 26 2020 at 20:22, on Zulip):

the longer it is the harder it is to one-off use it in testing and such, and imo a long name doesn't buy you much

Lokathor (Aug 26 2020 at 20:22, on Zulip):

rustc_unstable_on_stable is probably the clearest name so far

Joshua Nelson (Aug 26 2020 at 20:22, on Zulip):

see around https://discordapp.com/channels/273534239310479360/274215136414400513/746403450669105254

Joshua Nelson (Aug 26 2020 at 20:23, on Zulip):

johndoe: is there a way to get a nightly build from the same commit as the latest stable? I want to use unstable features but (a) I don't want to get any regressions introduced in stable..nightly and (b) nightly is often missing components.
koxiaet: You can set the RUSTC_BOOTSTRAP env variable I think
johndoe: I'll try RUSTC_BOOTSTRAP

simulacrum (Aug 26 2020 at 20:23, on Zulip):

I don't think we need to say "unstable on stable", just "unstable" seems enough to me. BOOTSTRAP is confusing because it has nothing to do with the flag's actual effect

Joshua Nelson (Aug 26 2020 at 20:23, on Zulip):

and the real concern I have with this is that a) someone suggested it and b) the beginner accepted it without knowing it was bad

simulacrum (Aug 26 2020 at 20:24, on Zulip):

I mean at some point that's just ... the reality of help

simulacrum (Aug 26 2020 at 20:24, on Zulip):

but sure, renaming to RUSTC_UNSTABLE or whatever seems not unreasaonble

Joshua Nelson (Aug 26 2020 at 20:24, on Zulip):

right, we can't fix a), but I think this would help with b)

cuviper (Aug 26 2020 at 20:28, on Zulip):

UNSTABLE indicates the effect, BOOTSTRAP the intended use case

cuviper (Aug 26 2020 at 20:28, on Zulip):

That change seems reasonable

triagebot (Aug 26 2020 at 20:30, on Zulip):

A new proposal has been announced: Require users to confirm they know RUSTC_BOOTSTRAP is unsupported before using it #350. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.

Joshua Nelson (Aug 26 2020 at 20:30, on Zulip):

https://github.com/rust-lang/compiler-team/issues/350, https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350

Joshua Nelson (Aug 26 2020 at 20:32, on Zulip):

previous discussion: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/how.20does.20release.20branching.20work.3F/near/208059954

nagisa (Aug 26 2020 at 20:35, on Zulip):

If I remember correctly we used to, in the far past, have a specific passcode that you needed to supply to RUSTC_BOOTSTRAP

nagisa (Aug 26 2020 at 20:35, on Zulip):

and it would change every release.

simulacrum (Aug 26 2020 at 20:35, on Zulip):

I'm going to move this discussion into the MCP stream

bjorn3 (Aug 26 2020 at 20:36, on Zulip):

Can we add a zero-width whitespace character in either the name or the value? That would make it much harder to type in a regular shell. Putting it in the name would probably be the harder option, as the value may have a way to escape arbitrary bytes.

Notification Bot (Aug 26 2020 at 20:36, on Zulip):

This topic was moved here from #general > how does release branching work? by simulacrum

Joshua Nelson (Aug 26 2020 at 20:36, on Zulip):

That would make it much harder to type in a regular shell.

I don't think that's really the point of the change

simulacrum (Aug 26 2020 at 20:36, on Zulip):

I am strongly opposed to making this hard to type

Joshua Nelson (Aug 26 2020 at 20:36, on Zulip):

we're not trying to make it difficult, we're trying to make it a conscious decision

cuviper (Aug 26 2020 at 20:39, on Zulip):

johndoe: is there a way to get a nightly build from the same commit as the latest stable? I want to use unstable features [...]

it sounds like this user would be perfectly happy to use it by another name anyway

Joshua Nelson (Aug 26 2020 at 20:39, on Zulip):

what I ended up suggesting was pinning a nightly

Joshua Nelson (Aug 26 2020 at 20:39, on Zulip):

and they were happy with that

Joshua Nelson (Aug 26 2020 at 20:41, on Zulip):

which is sort of what bootstrap uses it for too, except built in beta mode to catch things like https://github.com/rust-lang/rust/issues/75951

Vadim Petrochenkov (Aug 26 2020 at 20:58, on Zulip):

RUSTC_BOOTSTRAP is pretty useful for testing / debugging, even if it never goes to anything "release".

Vadim Petrochenkov (Aug 26 2020 at 20:59, on Zulip):

It shouldn't be made harder to use.

Joshua Nelson (Aug 26 2020 at 21:00, on Zulip):

the intention isn't to make it harder, but to make it more clear that it's not supported by the release team

Vadim Petrochenkov (Aug 26 2020 at 21:03, on Zulip):

Meh.
Renaming will only be a nuisance, isn't worth the bikeshedding and script-updating efforts.

simulacrum (Aug 26 2020 at 21:04, on Zulip):

I think if we do rename we'll keep both for at least a year or whatever

simulacrum (Aug 26 2020 at 21:04, on Zulip):

but I agree that I am uncertain about cost benefit here

nagisa (Aug 26 2020 at 21:05, on Zulip):

I think it is worthwhile to dig up the original discussion that ultimately led us to making RUSTC_BOOTSTRAP=1 as simple as it is today.

nagisa (Aug 26 2020 at 21:06, on Zulip):

I’m sure we were aware at the time of the fact that people will write these down in forums and possibly use them in a way we would rather them not to.

scottmcm (Aug 26 2020 at 21:07, on Zulip):

tossing things out there: RUSTC_BOOTSTRAP=1 could continue to work, but print a warning, which could either be suppressed normally or by setting RUSTC_BOOTSTRAP="I understand I'm opting out of stability".

Joshua Nelson (Aug 26 2020 at 21:07, on Zulip):

I think I like that better actually

Joshua Nelson (Aug 26 2020 at 21:07, on Zulip):

and maybe a link to why it's not recommended

simulacrum (Aug 26 2020 at 21:09, on Zulip):

Again, I don't want something longer than what we have today -- it's not worth the pain of typing it and piping it through tools

Joshua Nelson (Aug 26 2020 at 21:10, on Zulip):

simulacrum said:

Again, I don't want something longer than what we have today -- it's not worth the pain of typing it and piping it through tools

tools could still use RUSTC_BOOTSTRAP=1, just with a warning

simulacrum (Aug 26 2020 at 21:10, on Zulip):

I don't want different behavior when using this flag

scottmcm (Aug 26 2020 at 21:10, on Zulip):

(Suggestion inspired by the "Knock yourself out." banner on MIR output)

simulacrum (Aug 26 2020 at 21:10, on Zulip):

like, I'm fine with RUSTC_BOOTSTRAP=111 or something

simulacrum (Aug 26 2020 at 21:10, on Zulip):

it just shouldn't have spaces

Joshua Nelson (Aug 26 2020 at 21:11, on Zulip):

ok, that works

Camelid (Aug 26 2020 at 21:37, on Zulip):

Throwing this out there: RUSTC_UNSAFE_BOOTSTRAP

Joshua Nelson (Aug 26 2020 at 21:39, on Zulip):

Camelid said:

Throwing this out there: RUSTC_UNSAFE_BOOTSTRAP

that still doesn't say what it's doing though

Joshua Nelson (Aug 26 2020 at 21:39, on Zulip):

which is allowing you to use unstable features on stable

Eric Huss (Aug 26 2020 at 22:06, on Zulip):

nagisa said:

I think it is worthwhile to dig up the original discussion

https://github.com/rust-lang/rust/issues/36548

Josh Triplett (Aug 26 2020 at 22:09, on Zulip):

scottmcm said:

tossing things out there: RUSTC_BOOTSTRAP=1 could continue to work, but print a warning, which could either be suppressed normally or by setting RUSTC_BOOTSTRAP="I understand I'm opting out of stability".

I'm all for that. We can print a detailed message that explains what you're getting yourself into.

Josh Triplett (Aug 26 2020 at 22:10, on Zulip):

This is not a way to make it more difficult, or a way to shame people.

Josh Triplett (Aug 26 2020 at 22:10, on Zulip):

The only purpose of this is to make sure that nobody uses this without knowing what they're getting themselves into.

Josh Triplett (Aug 26 2020 at 22:11, on Zulip):

If someone does know what they're getting themselves into, so be it.

Josh Triplett (Aug 26 2020 at 22:12, on Zulip):

I want to see the "oooh, a shiny option to let me do what I want!" reaction slowed down a little bit, long enough for people to think about the implications.

Josh Triplett (Aug 26 2020 at 22:17, on Zulip):

Oh, minor nit: It should be RUSTC_UNSTABLE="I understand I am opting out of stability", not I'm, because let's not make people deal with quoting issues. ;)

Joshua Nelson (Aug 26 2020 at 22:18, on Zulip):

@Josh Triplett fyi simulacrum was not comfortable putting spaces in the required text: https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/Require.20users.20to.20confirm.20they.20know.20RUSTC_.E2.80.A6.20compiler-team.23350/near/208149128

Josh Triplett (Aug 26 2020 at 22:21, on Zulip):

@Joshua Nelson @simulacrum Ah, fair enough. I'm fine with modifying the text in question to eliminate the spaces.

simulacrum (Aug 26 2020 at 22:22, on Zulip):

Yeah spaces are bad for the same reason quote characters are bad

simulacrum (Aug 26 2020 at 22:23, on Zulip):

I would prefer something short but clear

simulacrum (Aug 26 2020 at 22:23, on Zulip):

(even something long is a bit annoying to remember the exact invocation of)

Josh Triplett (Aug 26 2020 at 22:26, on Zulip):

RUSTC_UNSTABLE=NO_STABILITY_GUARANTEES ?

simulacrum (Aug 26 2020 at 23:32, on Zulip):

a bit on the long side, imo

simulacrum (Aug 26 2020 at 23:32, on Zulip):

otoh, we could document and try to push people towards using that but also support, say, RUSTC_UNSTABLE=1

Joshua Nelson (Aug 27 2020 at 00:27, on Zulip):

If we do that then people end up copy/pasting RUSTC_UNSTABLE=1 :shrug: we do get the benefit that the name makes more sense but I think it doesn't got across that's it's unsupported

simulacrum (Aug 27 2020 at 01:12, on Zulip):

I personally do not really want to type NO_STABILITY_GUARANTEES every time I use this, and I don't know that the cost of misuse is that high

simulacrum (Aug 27 2020 at 01:12, on Zulip):

Maybe we could do RUSTC_CHANNEL=nightly?

simulacrum (Aug 27 2020 at 01:13, on Zulip):

that would sort of communicate you are switching to unstable channel

Joshua Nelson (Aug 27 2020 at 01:16, on Zulip):

I'd be ok with that

nagisa (Aug 27 2020 at 01:20, on Zulip):

That seems good. {RUSTC_,}FORCE_CHANNEL is another option.

Lokathor (Aug 27 2020 at 01:28, on Zulip):

and channel=nightly would make any compiler suddenly act like it was Nightly?

Camelid (Aug 27 2020 at 01:59, on Zulip):

Although RUSTC_CHANNEL=nightly seems like people would think that's how you use nightly features when usually you should use rustup to get a nightly toolchain. Maybe RUSTC_FEATURES=unstable?

Josh Triplett (Aug 27 2020 at 02:54, on Zulip):

@simulacrum How often do you type that by hand?

simulacrum (Aug 27 2020 at 02:55, on Zulip):

Probably roughly once a week? It's not terrible if it's long, I guess. We could also consider a sudo-like solution where you can add a .rustc-expert file in your home directory or so to let you use a shorter form

simulacrum (Aug 27 2020 at 02:55, on Zulip):

I mainly want to be able to remember it

simulacrum (Aug 27 2020 at 02:56, on Zulip):

(e.g., the cargo fingerprint logging i can never remember)

Josh Triplett (Aug 27 2020 at 02:56, on Zulip):

Mind if I ask what leads you to use it?

Josh Triplett (Aug 27 2020 at 02:57, on Zulip):

And to need to use it by hand rather than from a script?

simulacrum (Aug 27 2020 at 02:58, on Zulip):

Hm, I think it's mostly "invoking older compilers with -Z flags", usually for checking performance/assembly output, or simple bisection

simulacrum (Aug 27 2020 at 02:59, on Zulip):

If we have something long I'd probably have a rustc-unstable script

simulacrum (Aug 27 2020 at 03:00, on Zulip):

I would still be opposed to spaces or quotes to make it more likely that copy pasting it from e.g. failed rustc invocations just works

simulacrum (Aug 27 2020 at 03:00, on Zulip):

(Or will work once we print env variables there, I don't think we do today)

simulacrum (Aug 27 2020 at 03:02, on Zulip):

I also want to be able to give it to people when necessary without hunting down an invocation to copy paste, though I don't do that at all frequently

RalfJ (Aug 27 2020 at 07:34, on Zulip):

For people that use this regularly, another IMO reasonable option is to just write a simple shell wrapper that sets the env var

RalfJ (Aug 27 2020 at 07:35, on Zulip):

like, if you use it often enough that typing RUSTC_UNSTABLE=NO_STABILITY_GUARANTEES is actually annoying, then just make rbootstrap rustc ... work on your system (which is shorter than today)

RalfJ (Aug 27 2020 at 07:35, on Zulip):

There's few enough people that this applies to that IMO it's still justified

matklad (Aug 27 2020 at 09:21, on Zulip):

TBH, I'd like to see more examples of "users use RUSTC_BOOTSTAP and then are burnt by this" before we discuss the solution space here.

The example from https://discordapp.com/channels/273534239310479360/274215136414400513/746403450669105254 doesn't sound convincing to me personally -- if the person is asking "How can I find the nightly with the same commit as stable", they are probably knowledgeable enough about Rust's stability story to understand what they are doing.

From my own memory I can recall only a single instance of RUSTC_BOOTSTRAP misuse -- when simd_accel crate from Firefox set RUST_BOOTSTRAP in build.rs, and which than actually broke some code in the wild. That incident didn't have "I don't know what I am doing" factor to it.

Searching GitHub for RUSTC_BOOTSTRAP does not contradict that picture: https://github.com/search?l=Rust&p=6&q=RUSTC_BOOTSTRAP&type=Code

Almost all of hits are forks/copies of that single crate, with a couple of exceptions (which also set RUSTC_BOOTSTRAP in build.rs):

So, to sum up:

RalfJ (Aug 27 2020 at 09:33, on Zulip):

People were also suggesting that xargo should just set RUSTC_BOOTSTRAP to work on stable, against wish I pushed back strongly.

RalfJ (Aug 27 2020 at 09:34, on Zulip):

oh wow I didn't know crates can set this in their own build.rs... that's horrible, it means even when I am on a stable compiler and not doing anything like this myself, some of the crates I am using might do this!

RalfJ (Aug 27 2020 at 09:35, on Zulip):

I feel like a more explicit flag would help inform readers of such code that this is not a thing that they should just copy-paste

RalfJ (Aug 27 2020 at 09:36, on Zulip):

Right now there's some danger that "YOLO crates" get copied by people without them knowing the YOLO nature of what they are doing. I don't have any data to back this up, but I also wouldn't how how to collect such data -- the risk seems real enough to me.

matklad (Aug 27 2020 at 09:41, on Zulip):

I agree that making env var somewhat more self-describing will somewhat decrease the risk of accidental copy-paste. It's just my impression than accidental copy-paste is very infrequent problem, in this case.

For the buid.rs setting this env var, see https://github.com/rust-lang/cargo/issues/7088 and associated issues (warning: long, heated discussion)

Joshua Nelson (Aug 27 2020 at 12:53, on Zulip):

(actually a lot shorter than I expected)

Joshua Nelson (Aug 27 2020 at 12:55, on Zulip):

the general feeling I gathered from that is that people are ok with RUSTC_BOOTSTRAP=1 cargo build but not with it being in build.rs, because that means people that depend on your library are suddenly using unstable features without knowing it

Joshua Nelson (Aug 27 2020 at 12:55, on Zulip):

I do like @eddyb 's suggestion that this is per-binary, not per-environment, so that only the top-level crate can set it

Josh Triplett (Aug 27 2020 at 20:17, on Zulip):

I agree that this should not be settable from a build.rs script. I hadn't seen that particular issue.

Josh Triplett (Aug 27 2020 at 20:17, on Zulip):

There's a big difference between setting it yourself and having a crate set it for you.

Josh Triplett (Aug 27 2020 at 20:17, on Zulip):

The latter shouldn't be possible.

Josh Triplett (Aug 27 2020 at 20:18, on Zulip):

And I'd be happy to rfcbot merge a Cargo patch that just rejects an attempt to set RUSTC_BOOTSTRAP from build.rs.

nikomatsakis (Aug 28 2020 at 13:42, on Zulip):

"unstable on stable" is confusing to me

nikomatsakis (Aug 28 2020 at 13:43, on Zulip):

(as a name)

Jake Goulding (Aug 28 2020 at 14:19, on Zulip):

scottmcm said:

(Suggestion inspired by the "Knock yourself out." banner on MIR output)

Amusing side note, I think that original text was a throw-away suggestion from @pnkfelix when I wanted to stabilize --emit-mir for the playground's usage. I kept it as-is because I felt it accurately and light-heartedly conveyed the fact that the _contents_ were not stable.

nikomatsakis (Aug 28 2020 at 14:27, on Zulip):

I think it was mine!

nikomatsakis (Aug 28 2020 at 14:27, on Zulip):

(But I might be wrong.)

Jake Goulding (Aug 28 2020 at 14:49, on Zulip):

nikomatsakis said:

I think it was mine!

You are right

nikomatsakis (Aug 28 2020 at 15:03, on Zulip):

Sweet vindication

RalfJ (Aug 28 2020 at 17:17, on Zulip):

Interesting, I did not know about that cargo issue. FWIW, I am all in favor.

RalfJ (Aug 28 2020 at 17:20, on Zulip):

that issue also has some folks express frustration at things being stabilized too slowly. that is a fair point, but silently smuggling a dependency on unstable features into a dependency graph and thus subverting the stability guarantee is not an appropriate solution. (I'd post that in the issue but don't want to split the discussion.) the solution is to fix the stabilization process, not to smash it to pieces. rocket also survived and thrived nightly-only for years -- and conversely, just imagine the disaster if rocket started using that hack... I'd rather not.^^

RalfJ (Aug 28 2020 at 17:23, on Zulip):

specifically, @hsivonen (not sure of their zulip nick) writes

packed_simd is not at fault here. It has a rust-toolchain override, so even if you say rustup default stable, it picks your nightly compiler. However, if you try to build it as a dependency of another crate using the stable compiler, the build fails.

Yes, and that is a feature! A user using stable should be able to rely on stability, ergo, they should be sure that all crates they build (transitively) are stable-only.

RalfJ (Aug 28 2020 at 17:23, on Zulip):

this parallels what @Josh Triplett wrote above, to which I 100% agree:

There's a big difference between setting it yourself and having a crate set it for you.

Jake Goulding (Aug 28 2020 at 17:25, on Zulip):

Clearly we need an arms race, with another env variable DISALLOW_RUSTC_BOOTSTRAP that supersedes the current one :wink:

Josh Triplett (Aug 28 2020 at 17:26, on Zulip):

I think we're to the point of "please send a PR". If someone makes a PR to Cargo that prevents build.rs from setting RUSTC_BOOTSTRAP, I'll rfcbot merge it to confirm consensus.

bjorn3 (Aug 28 2020 at 17:29, on Zulip):

But some will then ask for DISALLOW_DISALLOW_RUSTC_BOOTSTRAP :stuck_out_tongue_wink:

RalfJ (Aug 28 2020 at 17:31, on Zulip):

Josh Triplett said:

I think we're to the point of "please send a PR". If someone makes a PR to Cargo that prevents build.rs from setting RUSTC_BOOTSTRAP, I'll rfcbot merge it to confirm consensus.

the issue says this is RFC material -- but I agree it feels to me like FCP is sufficient. not sure which teams though. lang and compiler?

Joshua Nelson (Aug 28 2020 at 17:34, on Zulip):

this seems like it's not part of lang?

Joshua Nelson (Aug 28 2020 at 17:34, on Zulip):

RUSTC_BOOTSTRAP has always been an implementation detail

Josh Triplett (Aug 28 2020 at 17:34, on Zulip):

@RalfJ The comment on that issue about an RFC was when someone tried to say "you can't change this unless we also talk about stability policy!".

Josh Triplett (Aug 28 2020 at 17:35, on Zulip):

@RalfJ Changes to RUSTC_BOOTSTRAP itself would probably want to be compiler-team consensus, potentially in consultation with other teams.

Josh Triplett (Aug 28 2020 at 17:36, on Zulip):

But changing cargo to prevent build.rs from setting it is something that I think can start in the Cargo team.

Josh Triplett (Aug 28 2020 at 17:37, on Zulip):

Joshua Nelson said:

this seems like it's not part of lang?

Agreed, this isn't a lang question at all. RUSTC_BOOTSTRAP itself is compiler, and if it needs broader consensus, probably core. build.rs is cargo, potentially in consultation with compiler, and if necessary core.

RalfJ (Aug 28 2020 at 17:39, on Zulip):

Josh Triplett said:

But changing cargo to prevent build.rs from setting it is something that I think can start in the Cargo team.

oh, I didnt know there was a cargo team that you're on. :) makes sense though.

Josh Triplett (Aug 28 2020 at 17:58, on Zulip):

Would someone be up for writing that patch?

Joshua Nelson (Aug 28 2020 at 18:10, on Zulip):

I might have time this weekend

Joshua Nelson (Aug 28 2020 at 18:10, on Zulip):

but if someone has time sooner feel free to beat me to it ;)

Josh Triplett (Aug 28 2020 at 18:14, on Zulip):

Quick guide for that change: src/cargo/core/compiler/custom_build.rs processes rustc-env directives from build.rs, so you'd need to add a check there, and anyhow::bail! in that case.

Josh Triplett (Aug 28 2020 at 18:14, on Zulip):

Then just add a test case. :)

matklad (Aug 28 2020 at 22:43, on Zulip):

Note that there's an existing patch for this, it might or might not make sense to rebase it: https://github.com/rust-lang/cargo/pull/6608

Joshua Nelson (Aug 28 2020 at 22:53, on Zulip):

hmm I'm reading through https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258 and it seems like this would make the firefox people very unhappy

Joshua Nelson (Aug 28 2020 at 22:55, on Zulip):

I'm ok writing the code for this but I don't feel very comfortable defending this change, especially when even the core team isn't sure what to do: https://github.com/rust-lang/cargo/pull/6608#issuecomment-459137496

Joshua Nelson (Aug 28 2020 at 22:57, on Zulip):

@Josh Triplett the code is here if you want it but I don't intend to make a PR with those changes: https://github.com/jyn514/cargo/tree/rustc-bootstrap

Josh Triplett (Aug 28 2020 at 22:58, on Zulip):

@Joshua Nelson Reading through that thread, it sounds to me like people agree that crates shouldn't be setting this on behalf of projects. We're not proscribing the use of RUSTC_BOOTSTRAP at all, we're just making it so crates can't silently opt into it, since it affects the overall project.

Joshua Nelson (Aug 28 2020 at 22:59, on Zulip):

sure, and if the cargo team wants to make that decision I have no objection

Joshua Nelson (Aug 28 2020 at 22:59, on Zulip):

but I don't want to be the face of the change

Josh Triplett (Aug 28 2020 at 22:59, on Zulip):

I'd be perfectly fine adding a finer-grained mechanism to allow opting in on a per-crate basis, as long as the opt-in was at the top level.

Josh Triplett (Aug 28 2020 at 22:59, on Zulip):

Joshua Nelson said:

but I don't want to be the face of the change

Sure, I understand that.

Josh Triplett (Aug 28 2020 at 23:00, on Zulip):

Do you object to your commit being used in someone else's pull request? I'm happy to send the PR.

Joshua Nelson (Aug 28 2020 at 23:02, on Zulip):

Not at all, go ahead :)

Josh Triplett (Aug 28 2020 at 23:02, on Zulip):

Also, I just thought of one other thing that we should probably do to make this simpler for people to deal with.

Josh Triplett (Aug 28 2020 at 23:02, on Zulip):

Could we make it so that if RUSTC_BOOTSTRAP is set to 1 in our environment, we don't do this?

Joshua Nelson (Aug 28 2020 at 23:03, on Zulip):

that seems reasonable

Josh Triplett (Aug 28 2020 at 23:03, on Zulip):

That way, if you go ahead and do RUSTC_BOOTSTRAP=1 cargo ... as suggested, it actually works.

Josh Triplett (Aug 28 2020 at 23:03, on Zulip):

And if people opt-in at the top level, as we're suggesting that they do, then they don't get this at all.

Josh Triplett (Aug 28 2020 at 23:03, on Zulip):

Rather than having to also go in and fix crates.

Joshua Nelson (Aug 28 2020 at 23:04, on Zulip):

Another thing I think should happen first is allowing per-crate rustc bootstrap

Joshua Nelson (Aug 28 2020 at 23:04, on Zulip):

Instead of a blanket 'everyome gets nightly'

Josh Triplett (Aug 28 2020 at 23:04, on Zulip):

That's a good call. For instance, RUSTC_BOOTSTRAP="foo bar" to make those named crates use nightly?

Josh Triplett (Aug 28 2020 at 23:04, on Zulip):

I like that idea very much.

Joshua Nelson (Aug 28 2020 at 23:04, on Zulip):

(not my idea originally: https://github.com/rust-lang/cargo/pull/6608#issuecomment-458546258)

Josh Triplett (Aug 28 2020 at 23:05, on Zulip):

That'd be a compiler change, I think, though technically Cargo could translate it.

Josh Triplett (Aug 28 2020 at 23:05, on Zulip):

I don't think Cargo should; I think it makes sense for rustc to do so.

Josh Triplett (Aug 28 2020 at 23:05, on Zulip):

But I agree that it's probably better to have that go in first.

Josh Triplett (Aug 28 2020 at 23:06, on Zulip):

And then cargo could avoid emitting the error if either RUSTC_BOOTSTRAP=1 or RUSTC_BOOTSTRAP split on words contains the crate name.

Josh Triplett (Aug 28 2020 at 23:07, on Zulip):

@Joshua Nelson First of all, thank you for implementing the Cargo side of this. I'm always happy to see more people contributing to Cargo.

Josh Triplett (Aug 28 2020 at 23:08, on Zulip):

Second: Would you be up for implementing the compiler side of this? 🥺

Joshua Nelson (Aug 28 2020 at 23:20, on Zulip):

Yeah I'd be much more comfortable doing that

Josh Triplett (Aug 28 2020 at 23:21, on Zulip):

Once that's in, I'll submit the Cargo PR with your (modified) commit.

Josh Triplett (Aug 28 2020 at 23:21, on Zulip):

Also, once that's in, we can tell people to use RUSTC_BOOTSTRAP="current_crate_name".

RalfJ (Aug 29 2020 at 09:56, on Zulip):

Btw, one thing occurred to me -- the use of RUSTC_BOOTSTRAP=1 on stable has quite a few parallels with code deliberately causing UB that "happens to work". In both cases Rust has some problem (like a stable feature missing or something not being possible within the confines of the language spec), and then people start working around it as they feel unable to fix the source problem, and this in turn causes some fundamental problems for the project as a hole.
I am saying this also because I recall @Josh Triplett being very wary of breaking crates that deliberately exploit UB.

Joshua Nelson (Aug 29 2020 at 12:25, on Zulip):

Josh Triplett said:

Second: Would you be up for implementing the compiler side of this? 🥺

This turned out to be somewhat hard to implement in rustc, because it wants to know stable/unstable extremely early in startup. It would be easier to implement this in Cargo as suggested by Josh Triplett , but I'm willing to try and add it rustc, it will just take a while.

Josh Triplett (Aug 29 2020 at 14:53, on Zulip):

I think it needs to be in rustc, because it needs to work without cargo.

Josh Triplett (Aug 29 2020 at 14:54, on Zulip):

@RalfJ I don't like breaking crates that used UB when there was no other way to do something and it worked in practice. Here, there is a solution: use nightly.

Josh Triplett (Aug 29 2020 at 14:55, on Zulip):

I don't have nearly as much sympathy for UB when we provide a solution and that solution existed and was known when the code was written.

Josh Triplett (Aug 29 2020 at 14:55, on Zulip):

Does that answer your question?

RalfJ (Aug 29 2020 at 15:08, on Zulip):

It does, thanks.

eddyb (Sep 24 2020 at 14:21, on Zulip):

hi

eddyb (Sep 24 2020 at 14:21, on Zulip):

I already wrote a comment here https://github.com/rust-lang/compiler-team/issues/350#issuecomment-698372654

eddyb (Sep 24 2020 at 14:22, on Zulip):

I haven't read all the discussion

eddyb (Sep 24 2020 at 14:22, on Zulip):

but I'll keep presenting my idea even if every single time nothing happens :P

eddyb (Sep 24 2020 at 14:22, on Zulip):

there's no reason to rely on env vars, it was entirely a "let's get something working" thing

eddyb (Sep 24 2020 at 14:23, on Zulip):

that we somehow have stuck with for, what, 5 years?

Jonas Schievink (Sep 24 2020 at 14:36, on Zulip):

Seems like a drawback to make stable rustc incapable of using nightly features. I use that very often to test things.

simulacrum (Sep 24 2020 at 14:39, on Zulip):

@Jonas Schievink I think eddyb is proposing we'd ship a rustc-unstable file on all channels, and you'd do something like RUSTC=$HOME/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc-unstable or so to get it

simulacrum (Sep 24 2020 at 14:39, on Zulip):

(or potentially $(rustup which rustc-unstable))

Jonas Schievink (Sep 24 2020 at 14:42, on Zulip):

Ah, I see, that could work, yeah

bjorn3 (Sep 24 2020 at 14:47, on Zulip):

Setting RUSTC means that cargo will recompile everything. You could then just as well switch to a nightly compiler.

Jonas Schievink (Sep 24 2020 at 15:05, on Zulip):

Urg, yeah

lcnr (Sep 24 2020 at 15:11, on Zulip):

I don't always have a nightly compiler for a past stable release, and when dealing with perf regressions I recently used RUSTC_BOOTSTRAP=1 cargo rustc -- -Zself-profile or something like this, which felt really useful to me. I feel like rustc-unstable adds more steps here which doesn't seem worth it to me.

lcnr (Sep 24 2020 at 15:12, on Zulip):

Can we emit a warning when using RUSTC_BOOTSTRAP, which imo might be enough to make this more obvious

lcnr (Sep 24 2020 at 15:13, on Zulip):

and the additional noise doesn't seem like a problem to me, as situations where RUSTC_BOOTSTRAP is appropriate are already quite special, so imo it's ok to annoy people with a warning here

Joshua Nelson (Sep 24 2020 at 15:17, on Zulip):

so there are several different issues with the current setup

Joshua Nelson (Sep 24 2020 at 15:19, on Zulip):
  1. New users don't know RUSTC_BOOTSTRAP is bad and use it because they saw it on the internet. This would be helped by a warning, splitting into binaries, or changing the name.
  2. Codebases with a legitimate use, like rustc and (controversially) firefox, can't set it granularly, so they have the risk of allowing other crates that shouldn't build on stable into their dependency tree. This would be helped by RUSTC_BOOTSTRAP=crate but not much else.

3. I forgot three, I'll try to think of it

Joshua Nelson (Sep 24 2020 at 15:20, on Zulip):

I think any changes we take should take both use cases into account

Joshua Nelson (Sep 24 2020 at 15:21, on Zulip):

and then there's a separate question of should there be legitimate uses other than finding compiler bugs, but I don't think we should try to tackle that here

est31 (Sep 24 2020 at 17:37, on Zulip):

bjorn3 said:

Setting RUSTC means that cargo will recompile everything. You could then just as well switch to a nightly compiler.

I've done the RUST_BOOTSTRAP thing myself for testing purposes and after I switch back to not using it, I get errors from crates that do auto-detection whether nightly features are available. Forgot which crate it was, but I think it's in cargo's dependency tree.

est31 (Sep 24 2020 at 17:38, on Zulip):

Oh I remember, it's anyhow

est31 (Sep 24 2020 at 17:39, on Zulip):

https://github.com/dtolnay/anyhow/blob/master/build.rs

est31 (Oct 02 2020 at 00:27, on Zulip):

Joshua Nelson said:

  1. New users don't know RUSTC_BOOTSTRAP is bad and use it because they saw it on the internet. This would be helped by a warning, splitting into binaries, or changing the name.
  2. Codebases with a legitimate use, like rustc and (controversially) firefox, can't set it granularly, so they have the risk of allowing other crates that shouldn't build on stable into their dependency tree. This would be helped by RUSTC_BOOTSTRAP=crate but not much else.

3. I forgot three, I'll try to think of it

Regarding 2: I've said it in other threads: Firefox can set it granularly. They could use a rustc wrapper and pass RUSTC_BOOTSTRAP to the wrapped rustc based on the crate name that the wrapper gets. That's no rocket science.

est31 (Oct 02 2020 at 00:29, on Zulip):

But if something gets done about RUSTC_BOOTSTRAP I'd be really glad. Two compiler binaries would be a good start.

Vadim Petrochenkov (Oct 02 2020 at 09:50, on Zulip):

est31 said:

Two compiler binaries would be a good start.

Good start into the bad direction, IMO.
If that happens, we'll need to at least ensure that the unstable rust binary is always shipped together with the stable one.
Right now env var is the most convenient and non-invasive way to unlock the nightly features if it becomes necessary.
I don't want to end up wanting --pretty=expanded to debug something now, but having to, for example, wait for several days for admins to install the necessary unstable components, which is a pretty realistic scenario in a corporate environment.

est31 (Oct 03 2020 at 21:06, on Zulip):

@Vadim Petrochenkov well in theory, with that proposal, the .so file is always around and you can always compile a custom nightly using rustc for it. I'm sure that someone will publish something like that to github once the problem arises. Your use case is legitimate though, often you want to test something on the precise same compiler version that compiles your thing for production.

RalfJ (Oct 04 2020 at 11:24, on Zulip):

The first step was mostly about making sure crates cannot "silently" move to nightly without the user even knowing, i.e., the build.rs problem... what is the status of that? https://github.com/rust-lang/cargo/issues/7088 didn't see any activity it seems.

Joshua Nelson (Oct 04 2020 at 12:50, on Zulip):

@RalfJ I wanted to make sure there was an alternative to RUSTC_BOOTSTRAP=1 before forbidding it, namely RUSTC_BOOTSTRAP=crate. That hasn't been implemented and I don't think it makes sense to forbid this in build scripts until it is

Joshua Nelson (Oct 04 2020 at 12:52, on Zulip):

(see https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Find.20the.20name.20of.20a.20crate.20before.20I.20know.20the.20edition.3F for some of the trouble I was having, I haven't worked on it in a while)

RalfJ (Oct 04 2020 at 13:11, on Zulip):

@Joshua Nelson that is a neat feature, but I dont think it should block the build.rs change

RalfJ (Oct 04 2020 at 13:11, on Zulip):

RUSTC_BOOTSTRAP=crate cargo build is better than RUSTC_BOOTSTRAP=1 cargo build but even that is better than cargo build just silently using the env var for some crates

Joshua Nelson (Oct 04 2020 at 13:13, on Zulip):

I mean, personally I disagree but I'm not on t-cargo and don't really have a stake in this fight ;) I'm just not willing to make the change myself until this is implemented

RalfJ (Oct 04 2020 at 13:34, on Zulip):

I hope this is not a fight :)

RalfJ (Oct 04 2020 at 13:35, on Zulip):

I recall @Josh Triplett supporting this change; Josh -- do you think this needs RUSTC_BOOTSTRAP=crate or can we disable the env var on the cargo side before having more fine-grained env var control?

nagisa (Oct 04 2020 at 14:04, on Zulip):

I support the eddyb approach if we're making a cough breaking cough change here.

nagisa (Oct 04 2020 at 14:05, on Zulip):

as for build.rs I vote filter out entirely

lcnr (Oct 04 2020 at 14:09, on Zulip):

from eddyb's comment https://github.com/rust-lang/compiler-team/issues/350#issuecomment-698372654

The important aspect, IMO, is that CI and distro build environments can remove access to it entirely, leaving the regular rustc incapable of turning into rustc-unstable, no matter its environment.

I really don't think that this is desirable. Using RUSTC_BOOTSTRAP is often very helpful when quickly looking at regressions so I don't want to see this made harder/impossible to do.

More explicitly warning when it is used (by either changing the name or emitting a warning everytime it is used) seems better to me

RalfJ (Oct 04 2020 at 14:11, on Zulip):

@lcnr what is your stanza re: RUSTC_BOOTSTRAP in build.rs? keep it, kill it ASAP, or kill it when we have RUSTC_BOOTSTRAP=crate?

lcnr (Oct 04 2020 at 14:12, on Zulip):

hmm, I guess it's an issue if it is used in a crate and the crate consumer does not notice this :thinking:

lcnr (Oct 04 2020 at 14:12, on Zulip):

imo a warning which can't be silenced would be enough there though

lcnr (Oct 04 2020 at 14:16, on Zulip):

though RUSTC_BOOTSTRAP has to always be used when bootstrapping the compiler afaik so always getting a warning there also doesn't seem great :/

cuviper (Oct 04 2020 at 14:18, on Zulip):

Distro rustc has to bootstrap the next rustc, so we can't kill that entirely

cuviper (Oct 04 2020 at 14:19, on Zulip):

Same goes for CI builds today, though I suppose that could start using alternate builds as stage0

nagisa (Oct 04 2020 at 14:27, on Zulip):

cuviper said:

Distro rustc has to bootstrap the next rustc, so we can't kill that entirely

Distros can choose to ship a package with unstable-enabled rustc driver, either separately, in a different output, or in the same output within libexec or similar.

Josh Triplett (Oct 04 2020 at 16:53, on Zulip):

@RalfJ In theory, it would be my preference to prohibit build.rs files from using RUSTC_BOOTSTRAP immediately. However, from a pragmatic point of view, as soon as we do that, people will adapt their build environments to start supplying that variable when they need to, and when we do that, I would like to have a better alternative for them to switch to that we could provide an automatic suggestion for. For example, we could detect that the build.rs script of the crate xyz is attempting to export RUSTC_BOOTSTRAP, and we could error out but suggest that they export RUSTC_BOOTSTRAP=xyz.

Josh Triplett (Oct 04 2020 at 16:54, on Zulip):

If we don't have that available, then people who encounter that error are likely to end up building their entire crate hierarchy using nightly, rather than just the one crate that wants it.

Josh Triplett (Oct 04 2020 at 16:56, on Zulip):

@Joshua Nelson How goes the change to support =crate?

Joshua Nelson (Oct 04 2020 at 17:01, on Zulip):

uhhh

Joshua Nelson (Oct 04 2020 at 17:01, on Zulip):

I have not put any much time into it

Josh Triplett (Oct 04 2020 at 17:24, on Zulip):

@Joshua Nelson No pressure, just wondered. Life happens. :)

est31 (Oct 07 2020 at 04:51, on Zulip):

Banning RUSTC_BOOTSTRAP in build.rs should be a no-brainer at this point. As I've said in the cargo threads, firefox can just use a rustc wrapper that passes RUSTC_BOOTSTRAP. That wrapper has to be set using .cargo/config which makes it much harder to upload "encapsulated nightly use" to crates.io without detection. The wrapper also gives them the desired control over what can use nightly and what can't because the rustc wrapper can parse the arguments passed to it and only set RUSTC_BOOTSTRAP for those crate names they are interested in.

est31 (Oct 07 2020 at 04:56, on Zulip):

Also as I understand it, firefox uses mach anyways instead of cargo

Josh Triplett (Oct 07 2020 at 15:16, on Zulip):

Firefox would be my primary concern, so if the folks there would accept needing to do that, I would happily rfcbot merge a cargo patch to filter that out of build.rs and warn.

Josh Triplett (Oct 07 2020 at 15:18, on Zulip):

Not error, because that would break existing crates and require revving them all to unbreak. But catching attempts to set RUSTC_BOOTSTRAP from build.rs and rejecting that with a warning sounds great.

RalfJ (Oct 10 2020 at 11:52, on Zulip):

Josh Triplett said:

Not error, because that would break existing crates and require revving them all to unbreak. But catching attempts to set RUSTC_BOOTSTRAP from build.rs and rejecting that with a warning sounds great.

with a plan to make this a hard error eventually, future-incompat style?

RalfJ (Oct 10 2020 at 11:52, on Zulip):

Josh Triplett said:

Firefox would be my primary concern, so if the folks there would accept needing to do that, I would happily rfcbot merge a cargo patch to filter that out of build.rs and warn.

what would be the best way to reach out to them?

Joshua Nelson (Oct 10 2020 at 19:01, on Zulip):

I opened https://github.com/rust-lang/rust/pull/77802.

Joshua Nelson (Oct 10 2020 at 19:19, on Zulip):

cc @Josh Triplett, I finally got around to it :laughing:

Josh Triplett (Oct 10 2020 at 21:04, on Zulip):

@RalfJ No, with a plan to make it an error immediately, but offer an alternative.

Josh Triplett (Oct 10 2020 at 21:04, on Zulip):

@RalfJ "reject it with a warning" was perhaps ambiguous.

Josh Triplett (Oct 10 2020 at 21:04, on Zulip):

I meant "reject it and provide a message"

Josh Triplett (Oct 10 2020 at 21:04, on Zulip):

@Joshua Nelson Reading.

RalfJ (Oct 11 2020 at 08:51, on Zulip):

Josh Triplett said:

I meant "reject it and provide a message"

oh, "warning" as in "continue the cargo build", but not actually with RUSTC_BOOTSTRAP set. understood.

Josh Triplett (Oct 11 2020 at 16:30, on Zulip):

Yes, exactly.

Joshua Nelson (Oct 11 2020 at 19:30, on Zulip):

related: now that RUSTC_BOOTSTRAP=0 is no longer going to have meaning, can we repurpose that to mean 'emulate a stable compiler on nightly'?

Joshua Nelson (Oct 11 2020 at 19:31, on Zulip):

It would be helpful for testing rustdoc's misuse of stability-dependent code, like https://github.com/rust-lang/rust/pull/75953 and https://github.com/rust-lang/rust/pull/77827

Josh Triplett (Oct 11 2020 at 20:47, on Zulip):

@Joshua Nelson Oh, I love that idea.

Josh Triplett (Oct 11 2020 at 20:47, on Zulip):

I really love that idea.

Josh Triplett (Oct 11 2020 at 20:48, on Zulip):

It'd also be nice to have an in-Rust-code equivalent that you can put at the top of a file, to opt out of nightly even on a nightly compiler.

Josh Triplett (Oct 11 2020 at 20:48, on Zulip):

But having a quick way to do that on the command line seems like a good plan.

Josh Triplett (Oct 11 2020 at 20:48, on Zulip):

Using RUSTC_BOOTSTRAP for that is...quirky, but amusing.

Josh Triplett (Oct 11 2020 at 20:48, on Zulip):

Might also make sense to do it with a separate dedicated variable.

Joshua Nelson (Oct 11 2020 at 20:48, on Zulip):

'I am not bootstrapping'

Joshua Nelson (Oct 11 2020 at 20:49, on Zulip):

sure, separate variable seems fine

Josh Triplett (Oct 11 2020 at 20:49, on Zulip):

Joshua Nelson said:

'I am not bootstrapping'

RUSTC_VENTURE_CAPITAL=1. ;)

Joshua Nelson (Oct 11 2020 at 20:50, on Zulip):

actually - someone mentioned RUSTC_FORCE_UNSTABLE a while ago, maybe eventually we could have both that and RUSTC_FORCE_STABLE

Joshua Nelson (Oct 11 2020 at 20:50, on Zulip):

I like both those names better than RUSTC_BOOTSTRAP

Joshua Nelson (Oct 11 2020 at 20:51, on Zulip):

and they could both support per-crate opt-in/out

Josh Triplett (Oct 11 2020 at 20:56, on Zulip):

I like that concept. Should be straightforward to modify your patch to use RUSTC_ALLOW_UNSTABLE=crate1,crate2 or similar, instead of modifying RUSTC_BOOTSTRAP.

RalfJ (Oct 11 2020 at 21:56, on Zulip):

Josh Triplett said:

It'd also be nice to have an in-Rust-code equivalent that you can put at the top of a file, to opt out of nightly even on a nightly compiler.

isn't that just "don't add any feature attribute"?

Joshua Nelson (Oct 11 2020 at 22:00, on Zulip):

Josh Triplett is suggesting something like forbid(features) I think

Joshua Nelson (Oct 11 2020 at 22:00, on Zulip):

Where adding a feature gives a compile error

Joshua Nelson (Oct 11 2020 at 22:01, on Zulip):

Although even that wouldn't help with rustdoc because it's bad at using feature gates :/

Joshua Nelson (Oct 11 2020 at 22:04, on Zulip):

Related: https://github.com/rust-lang/rust/issues/63305

Joshua Nelson (Oct 16 2020 at 00:18, on Zulip):

I asked on the PR but I'll ask again here: what's the path forward for https://github.com/rust-lang/rust/pull/77802 ? Do I need a new MCP? Should I update this one? Does it need FCP? I don't want it to hang in limbo forever.

simulacrum (Oct 16 2020 at 03:09, on Zulip):

I think an FCP would be appropriate. I can't kick that off myself, but I expect @Vadim Petrochenkov or @pnkfelix will when they get a chance (presuming they agree).

Vadim Petrochenkov (Oct 16 2020 at 22:55, on Zulip):

Done.

oliver (Oct 18 2020 at 03:41, on Zulip):

What about all the existing code and scripts using R..C_B..P=1?

Joshua Nelson (Oct 18 2020 at 03:42, on Zulip):

they'll still work

Joshua Nelson (Oct 18 2020 at 03:42, on Zulip):

the only thing that will break is people doing weird things like RUSTC_BOOTSTRAP=0, but I don't find that very compelling, especially this is not in any way stable

oliver (Oct 18 2020 at 03:43, on Zulip):

Codes and scripts using R..C_B..P=0 are okay as well?

Joshua Nelson (Oct 18 2020 at 03:44, on Zulip):

no, they'll break

Joshua Nelson (Oct 18 2020 at 03:44, on Zulip):

but =0 is weird and I don't know why you'd use it

oliver (Oct 18 2020 at 03:44, on Zulip):

Maybe only a few do

oliver (Oct 18 2020 at 03:44, on Zulip):

but there are some

Joshua Nelson (Oct 18 2020 at 03:45, on Zulip):

:shrug: if you're intentionally breaking rust's stability guarentees I'm not particularly included to be bug-for-bug compatible in helping you do it

oliver (Oct 18 2020 at 03:45, on Zulip):

It's not a problem since no one would ever do it

Joshua Nelson (Feb 24 2021 at 21:37, on Zulip):

RalfJ said:

lcnr what is your stanza re: RUSTC_BOOTSTRAP in build.rs? keep it, kill it ASAP, or kill it when we have RUSTC_BOOTSTRAP=crate?

FYI I ended up opening https://github.com/rust-lang/cargo/pull/9181, which is the "kill it when we have RUSTC_BOOTSTRAP=crate" option

Josh Triplett (Feb 24 2021 at 22:16, on Zulip):

@Joshua Nelson Is that PR now hack-free? Would you consider it ready for merge?

Joshua Nelson (Feb 24 2021 at 22:18, on Zulip):

@Josh Triplett it's hack free but there have been a lot of changes since the last review, I was hoping Eric Huss or another team member could take a look

Joshua Nelson (Feb 24 2021 at 22:19, on Zulip):

Also there's a TODO floating around I forgot to comment on

Josh Triplett (Feb 24 2021 at 22:19, on Zulip):

I looked it over, and I think the change to nightly_features_allowed seems reasonable to me.

Josh Triplett (Feb 24 2021 at 22:24, on Zulip):

Side note, I wonder if any build.rs scripts attempt to set RUSTFLAGS or similar?

Josh Triplett (Feb 24 2021 at 22:28, on Zulip):

I just responded to the TODO, and to one other open review comment.

Joshua Nelson (Feb 24 2021 at 22:34, on Zulip):

Josh Triplett said:

Side note, I wonder if any build.rs scripts attempt to set RUSTFLAGS or similar?

this seems fine though - I can imagine setting -C link-arg or something conditionally if you're linking a dependency statically or dynamically

Joshua Nelson (Feb 24 2021 at 22:51, on Zulip):

lcnr said:

though RUSTC_BOOTSTRAP has to always be used when bootstrapping the compiler afaik so always getting a warning there also doesn't seem great :/

note that setting BOOTSTRAP at the top level is not the same as setting it in build.rs. AFAIK nothing sets it in build.rs in rust-lang/rust, it just assumes it's being built with an unstable toolchain.

Joshua Nelson (Feb 24 2021 at 22:53, on Zulip):

(If something is setting that in build.rs, I'd personally consider it a bug)

Josh Triplett (Feb 25 2021 at 07:47, on Zulip):

Joshua Nelson said:

Josh Triplett said:

Side note, I wonder if any build.rs scripts attempt to set RUSTFLAGS or similar?

that seems fine though - I can imagine setting -C link-arg or something conditionally if you're linking a dependency statically or dynamically

Do you actually expect that that's used? You said "I imagine we'd break half the ecosystem if we prevented that", but do you really think half the ecosystem is setting those from build.rs?

Josh Triplett (Feb 25 2021 at 07:53, on Zulip):

@Joshua Nelson I just posted one more followup comment on the PR, regarding one other place that you changed to pass down config that you now shouldn't need to change anymore.

Joshua Nelson (Feb 25 2021 at 14:09, on Zulip):

Josh Triplett said:

do you really think half the ecosystem is setting those from build.rs?

$ rg rustc-env $CARGO_HOME/registry | tee env.txt

env.txt
Surprisingly I don't see RUSTFLAGS anywhere, although this is just what I happen to have cached locally, not the whole index.

I guess my real concern is I don't see any reason to forbid this. It doesn't break anything and it just makes life harder for the authors of build scripts.

Josh Triplett (Feb 25 2021 at 17:09, on Zulip):

I can think of several reasons. I wouldn't want a crate changing my target features, for instance.

Josh Triplett (Feb 25 2021 at 17:10, on Zulip):

Or passing -l rather than telling Cargo to link a library.

Josh Triplett (Feb 25 2021 at 17:21, on Zulip):

Or changing optimization flags.

Josh Triplett (Feb 25 2021 at 17:22, on Zulip):

I really can't think of any legitimate reason why a build script should ever be able to change RUSTFLAGS.

hyd-dev (Feb 25 2021 at 17:36, on Zulip):

Does setting RUSTFLAGS from build scripts have any effect?
It seems that rustc doesn't respect that environment variable:

$ RUSTFLAGS=invalid rustc - <<<'fn main() {}'
$ echo $?
0

And it's rustc-env, so Cargo probably doesn't read it?

bjorn3 (Feb 25 2021 at 17:40, on Zulip):

Nope. Doesn't have any effect.

Josh Triplett (Feb 25 2021 at 19:30, on Zulip):

Ah, even better.

Last update: May 07 2021 at 08:00UTC