ICE: -Z unstable-options without extra argument

[klutzy]

$ touch empty.rs && RUST_BACKTRACE=1 rustc empty.rs -Z unstable-options

error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'No option 'pretty' defined', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libgetopts/lib.rs:288

stack backtrace:
   1:     0x7f72e50e2130 - sys::backtrace::write::h34a8f70a4ca4ec0fy8t
   2:     0x7f72e5105860 - failure::on_fail::h88bfd016d2822c140jB
   3:     0x7f72e5071b20 - rt::unwind::begin_unwind_inner::haf8e45ff7ce022991YA
   4:     0x7f72e5072650 - rt::unwind::begin_unwind_fmt::h182b016b507efcdexXA
   5:     0x7f72dfa51dd0 - Matches::opt_vals::h0825e97fe157f173F5a
   6:     0x7f72dfa53200 - Matches::opt_default::h18c31216d9511db93ab
   7:     0x7f72e5711f60 - run_compiler::hb21c8df76397117cR8b
   8:     0x7f72e57106d0 - thunk::F.Invoke<A, R>::invoke::h13774937598519192257
   9:     0x7f72e570f630 - rt::unwind::try::try_fn::h9167027889745043865
  10:     0x7f72e5170bc0 - rust_try_inner
  11:     0x7f72e5170bb0 - rust_try
  12:     0x7f72e570f8e0 - thunk::F.Invoke<A, R>::invoke::h9295767165675113612
  13:     0x7f72e50f2030 - sys::thread::thread_start::h3f192e5a493c4515E3w
  14:     0x7f72df358fe0 - start_thread
  15:     0x7f72e4cfbc99 - __clone
  16:                0x0 - <unknown>

[japaric]

cc @alexcrichton

[alexcrichton]

Oh dear, sorry about that!

[mrmonday]

Just hit this myself - it would seem that the pretty option has disappeared too, making it very difficult to debug compiler plugins.

[Munksgaard]

I believe that this specific error has been fixed, only to be replaced by this:

$ touch empty.rs && RUST_BACKTRACE=1 rustc empty.rs -Z unstable-options
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'No option 'show-span' defined', /home/munksgaard/src/rust/src/libgetopts/lib.rs:293

stack backtrace:
   1:     0x7f3057a41f00 - sys::backtrace::write::hde4dc71c4c33b7c9L1y
   2:     0x7f3057a66300 - failure::on_fail::h25c49b66647ae6b0pcH
   3:     0x7f30579c42d0 - rt::unwind::begin_unwind_inner::h47f408c6e14ad979KQG
   4:     0x7f30579c4de0 - rt::unwind::begin_unwind_fmt::hee1681655e9b6171gPG
   5:     0x7f30522b7230 - Matches::opt_vals::ha882112fd1714097F5a
   6:     0x7f30522b8500 - Matches::opt_str::h4b4e5e14857cec0agbb
   7:     0x7f305810cd90 - run_compiler::h95361ebe24858b6b6bc
   8:     0x7f305810b3f0 - thunk::F.Invoke<A, R>::invoke::h7400904607630647539
   9:     0x7f305810a320 - rt::unwind::try::try_fn::h530882388650529344
  10:     0x7f3057add0d0 - rust_try_inner
  11:     0x7f3057add0c0 - rust_try
  12:     0x7f305810a5d0 - thunk::F.Invoke<A, R>::invoke::h18348562218329660567
  13:     0x7f3057a527f0 - sys::thread::thread_start::h6593a04931c6d32foQC
  14:     0x7f3051bb9140 - <unknown>
  15:     0x7f3057658bb9 - __clone
  16:                0x0 - <unknown>

Note that the unspecified options is now show-span instead of pretty.

[Munksgaard]

And it also happens if you simply do rustc -Z unstable-options help.

[rprichard]

If I understand correctly, the problem is that "show-span" is missing from the getopts::Matches here in run_compiler:

if sess.unstable_options() {
    sess.opts.show_span = matches.opt_str("show-span");
}

It's missing due to the way we parse unstable options in handle_options:

1. First we try to parse command-line arguments using an [OptGroup] that only defines the stable options. If we succeed, then we return a getopts::Matches that only records the results for the stable options. (show-span is an unstable option, so it is omitted in this case.)
2. If we failed, then maybe it was because the command-line had an unstable option on it. We parse arguments again, this time using a [OptGroup] value with both stable and unstable options. If this succeeds, and if we found -Z unstable-options in the result, then we return a getopts::Matches recording results for all options.

One obvious fix is to ensure that getopts::Matches records the unstable options whenever -Z unstable-options is set. If the first parse succeeds, but that flag is set, then reparse.

I think I have a fix; I'll test it.

[pnkfelix]

Is it worth considering adding one or more run-make tests covering these use-cases for invoking rustc itself? It sounds like having such a test would have prevented the prior -Z unstable-options implementation (I did not want to block #23274 on such a requirement, but it might be a nice followup task.)

[rprichard]

I think so. I'll look into it.

[pnkfelix]

@rprichard actually, doing this nicely might be harder than I initially thought, since in all the cases listed above, the rustc invocation is expected to return a non-zero error code, right?

... so the run-make test is going to need to grep through the output ... it does not sound like a very fun test to maintain ... hmm.

Update: I guess we could at least ensure that we do not emit internal compiler error; that is probably good enough.

[rprichard]

It's supposed to succeed quietly in the case where -Z unstable-options is passed. At one point, I had written a run-pass test to verify this, but I nixed it because running the test seemed wasteful. We could test this by adding -Z unstable-options to any existing test, but that conflates things, I think.

AFAIK, we don't have a test verifying that unstable options require -Z unstable-options to work.

[pnkfelix]

@rprichard I guess I was solely looking at the original description ... running rustc -Z unstable-options on a newly created empty.rs shouldn't quietly succeed. But clearly you have a different test in mind, so okay.

[rprichard]

Oh, right, the original test should still have failed for lack of a main function.