Forbid the -Z compiler flags from being used in beta and stable releases

[bstrie]

#19051 is the metabug for compiler flag stability, but that bug does not put forward a policy for the inclusion of compiler flags that are explicitly unstable. As per our policy for feature gates, we should prevent the unstable flags behind -Z from being used in beta and stable releases. The rationale is the same: given an interface, users will end up relying on it (especially with such an innocuous name as "-Z" to provide no warning as to its instability), and they will be peeved when it breaks.

I see no downside to removing these flags from the beta and stable releases. If this causes a groundswell of demand for a certain flag in the stable release, then that is an argument to stabilize it (and by failing to remove it from the stable releases, we are denying ourselves the feedback of which flags are useful).

[bstrie]

cc @aturon

[pnkfelix]

I would prefer we remove -Z stuff from the help output, but keep the flags in as a back door for compiler developers. In practice this is useful for e.g. trying to work through issues that only replicate in a particular context specific to that binary image.

[nrc]

Don't we deliberately have a -Zunstable-options option or something precisely for this case? In which case this seems unnecessary. Or perhaps more options should be made unstable if there is something specific to worry about?

cc @alexcrichton

[pnkfelix]

@nrc the proposal of this issue, as I interpreted it, was that all -Z options would become completely unavailable on the beta and stable channels. -Z unstable-options would not help, at least under my interpretation that it, like any other -Z option, would become unavailable.

(I guess we could do something funky like require that you pass -Z unstable-options to use any other -Z` option on beta or stable. At least then the word "unstable" word show up in the user's script or whatever. But that's pretty hackish.)

[alexcrichton]

The intention was to allow -Z only on nightly, but the change never ended up happening and it was concluded that it's not the end of the world if it leaks through. The CLI interface of both the compiler's flags (-Z and -C especially) and rustdoc's flags were never subject to a high amount of scrutiny, and are highly unlikely to be at this point. We need to of course message clearly that -Z may change in subtle fashions, but a comprehensive overhaul is unlikely to happen at this point.

[pnkfelix]

triage decision: Not going to block 1.0 release on doing this. And maybe we will not do it at all -- we are a little worried about de-facto stabilization of -Z flags by people just taking advantage of them, but we do not see a need to rush in a fix for 1.0.

[pnkfelix]

triage: P-medium

[bstrie]

I just read a blog post today where somebody is building Rust on ARM with -Z no-landing-pads. They're using nightly, thankfully, but that's only because no_std is unstable. Don't underestimate this problem.

[pnkfelix]

@bstrie do you think it would make any difference if use of any -Z option on beta/stable channels required one also pass -Z unstable-options as well? (Effectively forcing one to acknowledge that one is opting into an unstable subsystem?)

[bstrie]

@pnkfelix I'm unsure of how to proceed at this point, given that 1.0 has shipped. I think at some point we need to sit down and have a good look at all the flags that the compiler accepts and decide the fate of each, because that wasn't something we got around to before 1.0. Basically do what aturon and acrichto did for all the stdlib APIs in 1.0-beta.

[brson]

Closing in favor of #31847