Tracking issue for accepting unstable flags in stable compilers

[alexcrichton]

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:

• -Z - all debugging options in the compiler are intended to be unstable
• --pretty - the pretty printer is quite broken in various ways, and it's output is also generally quite unstable
• --unpretty - the flag and formats emitted here were not intended to be stable
• --error-format - 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 #31793, 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.

[Zoxc]

Can -C link-args, -C llvm-args join this list? Both need a replacement which acceps spaces (#30947)

[alexcrichton]

@Zoxc for now, no, those are both stable flags and this is just targeted at unstable flags.

[durka]

For myself I use -Z trace-macros and --pretty=expanded for debugging macros, though both need improvements in their output.

I also use -Z no-trans for a faster compile-edit cycle, so I can fix all the errors before even trying the slow translation/linking steps. And I use cargo clippy for extra lints, which uses this flag internally (I think cargo check does too). Something like it should probably be stabilized with a different name.

cargo clippy also uses -Z extra-plugins.

[jrvidal]

I also use -Z no-trans for a faster compile-edit cycle

+1 on this.

(I'm guessing "+1" comments are fine in this thread...?)

[nagisa]

--pretty and --unpretty should probably be -Z pretty/unpretty instead. cc @nikomatsakis

[mkpankov]

Note that passing -Z no-trans disables some errors. In particular, type size comparison done when checking if std::mem::transmute should be allowed is not performed.

See this example: https://is.gd/cnjaFI . When run locally with -Z no-trans, no errors are reported.

Also, I'd like to point out that many linters are using -Z no-trans. 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?

[psFried]

Regardless of whether -Z no-trans 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.

[nikomatsakis]

@psFried I believe the plan was to make -Z no-trans more official, something like -C check. We should actually do this, however.

[brson]

Nominating to consider converting to an error.