Rust: Missing right parenthesis panics the compiler

[nakacristo]

I wrote some shitty code here: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=d44eb1015f294e937d86b157339d0978
And it broke the compiler. Apparently by reaching supposedly unreachable code of a parsing function.

Some background can be found at https://users.rust-lang.org/t/the-squeeze-challenge/25762/10
As pointed by @cuviper the problem can be reduced to

trait Howness {}
impl Howness for (){
    fn how_are_you(&self->Empty
    {
        Empty
    }
}

[jethrogb]

I-ICE regression-from-stable-to-beta

[cuviper]

Here's the backtrace from the reduced case:

thread 'rustc' panicked at 'internal error: entered unreachable code', src/libsyntax/parse/parser.rs:648:22
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   5: std::panicking::begin_panic
   6: syntax::parse::parser::Parser::parse_fn_decl_with_self
   7: syntax::parse::parser::Parser::parse_impl_item
   8: syntax::parse::parser::Parser::parse_item_implementation
   9: syntax::parse::parser::Parser::parse_item_
  10: syntax::parse::parser::Parser::parse_item
  11: syntax::parse::parser::Parser::parse_mod_items
  12: syntax::parse::parser::Parser::parse_crate_mod
  13: syntax::parse::parse_crate_from_file
  14: rustc_driver::driver::phase_1_parse_input::{{closure}}
  15: rustc::util::common::time
  16: rustc_driver::driver::phase_1_parse_input
  17: rustc_driver::driver::compile_input
  18: <scoped_tls::ScopedKey<T>>::set
  19: rustc_driver::run_compiler
  20: <scoped_tls::ScopedKey<T>>::set
  21: syntax::with_globals
  22: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  23: <F as alloc::boxed::FnBox<A>>::call_box
  24: std::sys::unix::thread::Thread::new::thread_start
             at /rustc/350674b7180a41c8e508d93c6ab8e203b69d3df7/src/liballoc/boxed.rs:759
             at src/libstd/sys_common/thread.rs:14
             at src/libstd/sys/unix/thread.rs:80
  25: start_thread
  26: __clone

[jethrogb]

Further reduced test case:

impl a {
  fn b(self>
}

[OptimisticPeach]

Woah, how is the compiler even supposed to be able to deal with such malformed syntax?

[jethrogb]

@OptimisticPeach it can throw an error (as it does on stable), it just shouldn't ICE.

[jethrogb]

Different possibly related bug:

struct A<B: !C

Backtrace:

thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:478
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   6: rust_begin_unwind
             at src/libstd/panicking.rs:312
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::panicking::panic
             at src/libcore/panicking.rs:49
   9: syntax::parse::parser::Parser::parse_generic_bounds_common
  10: syntax::parse::parser::Parser::parse_generic_params
  11: syntax::parse::parser::Parser::parse_generics
  12: syntax::parse::parser::Parser::parse_item_implementation
  13: syntax::parse::parser::Parser::parse_item_
  14: syntax::parse::parser::Parser::parse_item
  15: syntax::parse::parser::Parser::parse_mod_items
  16: syntax::parse::parser::Parser::parse_crate_mod
  17: syntax::parse::parse_crate_from_file
  18: rustc_driver::driver::phase_1_parse_input::{{closure}}
  19: rustc::util::common::time
  20: rustc_driver::driver::phase_1_parse_input
  21: rustc_driver::driver::compile_input
  22: <scoped_tls::ScopedKey<T>>::set
  23: rustc_driver::run_compiler
  24: <scoped_tls::ScopedKey<T>>::set
  25: syntax::with_globals
  26: __rust_maybe_catch_panic
             at src/libpanic_unwind/lib.rs:87
  27: <F as alloc::boxed::FnBox<A>>::call_box
  28: std::sys::unix::thread::Thread::new::thread_start
             at /rustc/350674b7180a41c8e508d93c6ab8e203b69d3df7/src/liballoc/boxed.rs:759
             at src/libstd/sys_common/thread.rs:14
             at src/libstd/sys/unix/thread.rs:80
  29: start_thread
  30: clone

Thanks to @OptimisticPeach for finding it.

[jethrogb]

I think that's #58857

[jethrogb]

@estebank maybe 7451cd8dc0b?

[estebank]

@jethrogb looks likely.

[estebank]

I believe I can have a fix shortly.

Edit:

I believe it is caused when calling unexpected,

https://github.com/rust-lang/rust/blob/c1d2d83ca3b5155468ab96b09a7c54568449b137/src/libsyntax/parse/parser.rs#L6336

which _expects_ to fail,

https://github.com/rust-lang/rust/blob/c1d2d83ca3b5155468ab96b09a7c54568449b137/src/libsyntax/parse/parser.rs#L645-L650

but the recovery mechanism makes it succeed

https://github.com/rust-lang/rust/blob/c1d2d83ca3b5155468ab96b09a7c54568449b137/src/libsyntax/parse/parser.rs#L833-L835

[estebank]

@OptimisticPeach gracefully :)

[pnkfelix]

triage: P-high. estebank is on it so assigning them.