Change:
RustcOptGroup { opt_group: g, stability: OptionStability::Stable } } <del> #[allow(dead_code)] // currently we have no "truly unstable" options </del> pub fn unstable(g: getopts::OptGroup) -> RustcOptGroup { RustcOptGroup { opt_group: g, stability: OptionStability::Unstable } } <del> fn unstable_bnr(g: getopts::OptGroup) -> RustcOptGroup { RustcOptGroup { opt_group: g, stability: OptionStability::UnstableButNotReally, } } </del> } // The `opt` local module holds wrappers around the `getopts` API that

Discussion:
This issue is intended to track the process of fixing rustc to not accept unstable flags on stable compilers. It's somewhat of a historical mistake that this was allowed, and we're attempting now to repair the logic to disallow unstable flags on the compiler. Today the compiler has a few unstable flags: - all debugging options in the compiler are intended to be unstable - the pretty printer is quite broken in various ways, and it's output is also generally quite unstable - the flag and formats emitted here were not intended to be stable - this support is currently experimental in the compiler and may not be ready for prime-time For backwards compatibility the compiler will continue to accept these flags on the stable and beta channels of Rust. In , however, the compiler will start to issue a warning on these channels whenever these flags are passed. The warning message points at this issue. The next steps on this issue are likely: Wait for the warning to propagate to the stable channel Get feedback about which unstable flags are widely used today Resolve how to stabilize widely used unstable flags Wait for these flags to be stable Turn the warning of unstable flags on the stable channel into a hard error If you're coming to this issue via the compiler warning, please feel free to comment with your flag and use case! We're eager to learn which unstable flags are most widely used to prioritize what to stabilize.
Can -C link-args, -C llvm-args join this list? Both need a replacement which acceps spaces ()
for now, no, those are both stable flags and this is just targeted at unstable flags.
For myself I use and for debugging macros, though both need improvements in their output. I also use for a faster compile-edit cycle, so I can fix all the errors before even trying the slow translation/linking steps. And I use for extra lints, which uses this flag internally (I think does too). Something like it should probably be stabilized with a different name. also uses .
+1 on this. (I'm guessing "+1" comments are fine in this thread...?)
and should probably be instead. cc
Note that passing disables some errors. In particular, type size comparison done when checking if should be allowed is not performed. See this example: . When run locally with , no errors are reported. Also, I'd like to point out that many linters are using .

This itself doesn't justify its stabilization, especially considering the example above that isn't checked correctly with the option. But, there probably should be another, stable, option, then, which would serve the purpose of linting. It should check for all possible errors and drop the translation as soon as all possible. Or should we wait for linting support in IDE oracle?
Regardless of whether disables some checks, I think it's still very nice to have in the stable compiler. Ideally, the long term solution would be for linters and IDE's to use the oracle once it's ready, but I think it's important in the mean time to have a fast check that catches most compile errors. This is especially important for those who are new to the language and will ofter require many revisions in order to get their code compiling.
I believe the plan was to make more official, something like . We should actually do this, however.
Nominating to consider converting to an error.
This will break using with stable compiler.
Have any of the useful flags people mentioned (no-trans, time-passes, pretty-expanded, trace-macros) been moved to stable equivalents/alternatives? (I think the answer is no.) If not, I think we shouldn't make this an error yet, since (supposedly) the intent was to keep useful functionality available, while being mindful about what gets stabilized. Without that it's kind of a bait-and-switch. On Jul 17, 2016 08:27, "Seo Sanghyeon" wrote: This will break using -Z time-passes with stable compiler. — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .
yes that's the intention, if it's a desirable flag to be on stable it should be stable. no, nothing has change, but that's because there doesn't seem to be that much desire to move these flags to stable.
is an example of using with stable, in this case to diagnose hang.
I mean, why even ask in this issue for people's use cases if the answers weren't going to matter? Sure, go ahead and error everything out and see who complains.

On Jul 19, 2016 07:12, "Seo Sanghyeon" wrote:
Hmm, I think we should considering making a stable variant of at least -- and probably the other flags too. Regarding the other flags that were mentioned (time-passes, pretty-expanded, trace-macros): All of these have in common that I feel more comfortable with stabilizing the ability to access said functionality than I do with stabilizing anything about the output. For example, I'd expect to look different over time (obviously, the set of passes will change, but also maybe the data we collect). Similary, pretty-expanded relies on our pretty printer, which I hope we will remove someday: I could imagine a new version looking quite different, or emitting only JSON, or something else. What this means is that humans using these switches would probably be fine, but tools would break. Do we think we can realistically declare a stability level of that kind? I guess it is the same as (for example) our general error output, which we expect to change. (We probably want to consider explicit scripting commands like git offers.)
Compiler team's current thinking: Its too soon to switch off all support for all current flags. There is a set of useful flags for debugging that we have no means of expression via or other stable interface. But something we may be able to do in the short term is white list a small subset of flags to be still accepted in nightly (as today), and make all others an error. What small subset? We suggest starting with any that appear in comments on this thread. Get to it people!!! Add them below if not already above!
The contentious flags are these used for debugging user code. I don't feel like they should have the same stability semantics as normal flags. Maybe have or something.
It does seem like there is room to have flags that, at minimum, have undefined output. Which effectively means they are unstable and can't really be used for scripting. I am thinking of things like gcc's "dump ast" flags ().
If there is an answer to how we want to stabilize I would love to use it as an "entry-level" PR for , if yinz don't mind.
Also is useful for linters.

This has sat here for quite awhile now, so I'd like to propose that we "stabilize" this in the sense that we fully gate the compiler flag on the stable/beta channels. This means that today what is a warning will turn into a hard error when implementing this. The major flag here used, , is now implemented as . fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] [x] Concerns: with the change being planned here, will the and / flags continue to be available with the bootstrap builds? () Once these reviewers reach consensus, 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 for info about what commands tagged team members can give me.
I am concerned that we will lose basic performance statistics on stable (). Discussion above seems to indicate we are hesitant to stabilize this because it's output and very nature can change, but I'm not sure how big of a problem that is. Perhaps it could keep issuing the warning we currently issue?
If we really want to be stable, then I'd encourage an issue/proposal to stabilize that rather than delaying this change, personally
Yeah, I don't have an overly strong opinion on it. Just wanted to bring it up. Just something to think about.
I agree, except that I would definitely not want to "stabilize" the output of in the sense of "guarantee that anything remotely similar gets output". But having an option like or something seems ok. In particular, as we move to a more "demand-driven" architecture, the whole idea of "compiler passes" is going to become less clear. I'd still expect we will want to have ways to profile where the compiler is spending its time. But it's not going to look much like it looks today.
Could we stabilize "a command line flag named XYZ exists and makes the compiler output some sort of timing information" without stabilizing what that information is and how it’s formatted?

Sorry if I'm intruding here, but what if took an argument, so that you could stabilize (say) and in the future, add another argument for any new style of output?
Or even use Git nomenclature and name it —self-profile=porcelain and assume that porcelain is prone to change. Łukasz Niemier
(trying to follow git's lead might be confusing, given that the option, at least in some contexts, is used to indicate that the output is stable ... see also )
I know, Git has it own strange tidbits that unfortunately still wasn't fixed (maybe v3). However we could adapt similar ideology to provide unstable output with stable compiler and in future provide stable one with appreciate flag.
This is what I want to do yeah.
Is there any possibility of changing to an option? I'd love to be able to use that for the alternative playground. Is it possible to stabilize the concept of outputting MIR even if the actual text form completely changes?
I know the worry is people bundling things into automated scripts that parse rustc output, but it does seem like we need to find a way to stabilize options without stabilizing their output format. , Jake Goulding <:
I guess we should also consider that there might come a time where MIR no longer even exists (it didn't in Rust 1.0, afterall! ). In that case, I even think it would be fine to print the text "MIR was removed in Rust 1.99, nothing to see here!". Pedantically, we say we output LLVM IR, but we certainly don't control the format of that. And it's already changed incompatibly as Rust has upgraded LLVM over time. Maybe we are worrying more than we need to be?
The whole point of emiting MIR is for debugging. has little use to compiler devs by now, because simply provides more information. In that sense its in the same position as – useful for debugging the compiler and nothing else. is most likely to just get merged into (incompatible output format, files instead stdout). Comparing MIR output to LLVM-IR/LLVM-BC is unfair here IMO and it should rather be compared with the instead. Why? Because in both cases this output, when paired with an appropriate version of a tool, will end up in asm or object.

In that sense LLVM-IR/BC output is stable. There are no (and never should be any) tools for parsing the MIR dumps.
I'm totally OK with whichever format... But for my own selfish reasons, I'd prefer that the MIR for the entire crate be output into a single file (just like LLVM-IR and ASM), as well as being triggered by . This is just to make my life easier. How picky should we be about this aspect? The .
concern bootstrap-rustc-builds with the change being planned here, will the and / flags continue to be available with the bootstrap builds? There are occasional times where I need to resort to looking at expanded output annotated with node-ids in order to make sense of ICE's that occur from a bootstrap compiler that I am in the process of constructing.
Nowadays all you have to do is set .
resolved bootstrap-rustc-builds (I'm assuming that whatever else is happening based on the change proposed here, will remain as a way to bypass the stability checks and allow one to again use .)
One problem I noticed with this issue is that Cargo doesn't detect what version of rust is running before passing -Z flags. As a real example, I've enabled CARGO_INCREMENTAL on one of my computers, and it recently ran into a bug on the nightly compiler. I've fallen back to the stable compiler for now, but I get warning about -Zincremental being passed due to this issue. It would be good if Cargo avoided passing -Z flags to rust before it becomes a hard error. Would it help if I filed an issue about this against cargo?
see
See also issue .
All major stakeholders have checked in with checkboxes above, and this was re-reviewed during tools triage yesterday, and I've now opened a PR:
Removing also breaks .
we've spent the last year printing that this is going to become an error. will still work on nightly, as is expected.