ICE: -Z unstable-options without extra argument #21715

Activity

1. japaric commented on Jan 28, 2015

   

   japaric

   on Jan 28, 2015

   Contributor

   More actions

   cc @alexcrichton
2. sanxiyn

   added

   I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️

   on Jan 28, 2015
3. alexcrichton commented on Jan 28, 2015

   

   alexcrichton

   on Jan 28, 2015

   Member

   More actions

   Oh dear, sorry about that!
4. mrmonday commented on Feb 4, 2015

   

   mrmonday

   on Feb 4, 2015

   Contributor

   More actions

   Just hit this myself - it would seem that the pretty option has disappeared too, making it very difficult to debug compiler plugins.
5. Munksgaard commented on Feb 10, 2015

   

   Munksgaard

   on Feb 10, 2015

   Contributor

   More actions

   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.
6. Munksgaard commented on Feb 10, 2015

   

   Munksgaard

   on Feb 10, 2015

   Contributor

   More actions

   And it also happens if you simply do rustc -Z unstable-options help.
7. rprichard commented on Mar 8, 2015

   

   rprichard

   on Mar 8, 2015

   Contributor

   More actions

   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.
8. pnkfelix commented on Mar 11, 2015

   

   pnkfelix

   on Mar 11, 2015

   Contributor

   More actions

   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.)
9. rprichard commented on Mar 11, 2015

   

   rprichard

   on Mar 11, 2015

   Contributor

   More actions

   I think so. I'll look into it.
10. pnkfelix commented on Mar 11, 2015

    

    pnkfelix

    on Mar 11, 2015

    Contributor

    More actions

    @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.
11. rprichard commented on Mar 11, 2015

    

    rprichard

    on Mar 11, 2015

    Contributor

    More actions

    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.
12. pnkfelix commented on Mar 11, 2015

    

    pnkfelix

    on Mar 11, 2015

    Contributor

    More actions

    @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.
13. rprichard commented on Mar 11, 2015

    

    rprichard

    on Mar 11, 2015

    Contributor

    More actions

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

    added a commit that references this issue on Mar 12, 2015

    Rollup merge of rust-lang#23274 - rprichard:fix-21715, r=pnkfelix

    ...

    This issue will close once commit e4e5640 is merged into the 'master' branch.

    e4e5640
15. bors

    closed this as completedin #23274on Mar 12, 2015