Thread 'rustc' panicked at 'internal error: entered unreachable code'

[ZhangZhuoSJTU]

Code

fn p([=(}

Another case from #86086:

trait Tr {
    fn union(#[]
}

The md5 of poc.rs is: a70b98c9f88da9731e44e3888bc0b8de

Meta

It is test with nightly, beta, and stable versions.

rustc --version --verbose:

rustc 1.51.0-nightly (4f4656d46 2021-02-04)
binary: rustc
commit-hash: 4f4656d46d84a488ae3df34b08f362d7071036a0
commit-date: 2021-02-04
host: x86_64-unknown-linux-gnu
release: 1.51.0-nightly
LLVM version: 11.0.1

rustc 1.50.0-beta.8 (1cd030396 2021-01-20)
binary: rustc
commit-hash: 1cd0303963629f317a08e7e52162ccca7232ae7f
commit-date: 2021-01-20
host: x86_64-unknown-linux-gnu
release: 1.50.0-beta.8

rustc 1.49.0 (e1884a8e3 2020-12-29)
binary: rustc
commit-hash: e1884a8e3c3e813aada8254edfa120e85bf5ffca
commit-date: 2020-12-29
host: x86_64-unknown-linux-gnu
release: 1.49.0

Error output

The output is from nightly.

error: this file contains an unclosed delimiter
 --> crash.rs:1:11
  |
1 | fn p([=(}
  |     --    ^
  |     ||
  |     |unclosed delimiter
  |     unclosed delimiter

error: expected pattern, found `=`
 --> crash.rs:1:7
  |
1 | fn p([=(}
  |       ^ expected pattern

error: expected one of `)`, `,`, `->`, `;`, `where`, or `{`, found `]`
 --> crash.rs:1:11
  |
1 | fn p([=(}
  |        - -^
  |        | |
  |        | help: `)` may belong here
  |        unclosed delimiter

thread 'rustc' panicked at 'internal error: entered unreachable code', compiler/rustc_parse/src/parser/item.rs:1615:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.51.0-nightly (4f4656d46 2021-02-04) running on x86_64-unknown-linux-gnu

query stack during panic:
end of query stack
error: aborting due to 3 previous errors

Backtrace

error: this file contains an unclosed delimiter
 --> crash.rs:1:11
  |
1 | fn p([=(}
  |     --    ^
  |     ||
  |     |unclosed delimiter
  |     unclosed delimiter

error: expected pattern, found `=`
 --> crash.rs:1:7
  |
1 | fn p([=(}
  |       ^ expected pattern

error: expected one of `)`, `,`, `->`, `;`, `where`, or `{`, found `]`
 --> crash.rs:1:11
  |
1 | fn p([=(}
  |        - -^
  |        | |
  |        | help: `)` may belong here
  |        unclosed delimiter

thread 'rustc' panicked at 'internal error: entered unreachable code', compiler/rustc_parse/src/parser/item.rs:1615:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4f4656d46d84a488ae3df34b08f362d7071036a0/library/std/src/panicking.rs:493:5
   1: core::panicking::panic_fmt
             at /rustc/4f4656d46d84a488ae3df34b08f362d7071036a0/library/core/src/panicking.rs:92:14
   2: core::panicking::panic
             at /rustc/4f4656d46d84a488ae3df34b08f362d7071036a0/library/core/src/panicking.rs:50:5
   3: rustc_parse::parser::item::<impl rustc_parse::parser::Parser>::parse_item_common_
   4: rustc_parse::parser::item::<impl rustc_parse::parser::Parser>::parse_item_common
   5: rustc_parse::parser::item::<impl rustc_parse::parser::Parser>::parse_mod
   6: rustc_parse::parse_crate_from_file
   7: rustc_session::utils::<impl rustc_session::session::Session>::time
   8: rustc_interface::passes::parse
   9: rustc_interface::queries::Queries::parse
  10: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  11: rustc_span::with_source_map
  12: rustc_interface::interface::create_compiler_and_run
  13: rustc_span::with_session_globals
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.51.0-nightly (4f4656d46 2021-02-04) running on x86_64-unknown-linux-gnu

query stack during panic:
end of query stack
error: aborting due to 3 previous errors

[osa1]

Because we already emit some correct errors a potential fix would be to just remove the problematic unreachable and return an empty function body.

However there's another problem; eat_to_tokens call in parse_fn_params generates non-existing tokens outside of the file to close all unmatched brackets. That's why we see column 11 in the error message even though column of the last token is 9 in the source file. parse_token_tree called by eat_to_tokens (called by parse_fn_params to recover from the invlid argument when seeing = which is invalid in pattern context) first generates ) at column 9 (which is actually the location of }), which I guess (didn't check) shifts } to column 10, which is somehow skipped and some other function inserts ] (couldn't figure out which function) at column 11. As a result we get this error that points to outside of the file

error: expected one of `)`, `,`, `->`, `;`, `where`, or `{`, found `]`
 --> test.rs:1:11
  |
1 | fn p([=(}  
  |        - -^
  |        | |
  |        | help: `)` may belong here
  |        unclosed delimiter

[hameerabbasi]

Is there an expected buffer overrun here or is it guarded?

[apiraino]

Assigning P-medium as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

[dwrensha]

I ran cargo-bisect-rustc and some finer-grained manual bisection.

The regression happened in ff61949.

cc @estebank

[estebank]

I'm guessing is because of this code branch: ff61949#diff-6315a286b68ae6d04785441a5a8257cee4b533c65e8cd007a8c679bf57a8301cR1590

I haven't checked to see how it could even get to it, as looking at the code it should be unreachable.

[FabianWolff]

@osa1

However there's another problem; eat_to_tokens call in parse_fn_params generates non-existing tokens outside of the file to close all unmatched brackets. That's why we see column 11 in the error message even though column of the last token is 9 in the source file.

Actually, this is caused by a different problem (#86076), because if you try the same code without a trailing newline, this behavior doesn't occur (the error message then points to column 10, which is correct, as it is the location of the EOF token). The spurious found `]` is an unrelated issue, which I have filed separately (#86073).

[JohnTitor]

Fixed by #87646 but there's no regression test for this case, marking as E-needs-test.