Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parser: don't use unreachable!() in fn unexpected. #66361

Merged
merged 1 commit into from
Nov 14, 2019
Merged

parser: don't use unreachable!() in fn unexpected. #66361

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion src/librustc_parse/parser/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -443,7 +443,9 @@ impl<'a> Parser<'a> {
crate fn unexpected<T>(&mut self) -> PResult<'a, T> {
match self.expect_one_of(&[], &[]) {
Err(e) => Err(e),
Ok(_) => unreachable!(),
// We can get `Ok(true)` from `recover_closing_delimiter`
// which is called in `expected_one_of_not_found`.
Ok(_) => FatalError.raise(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remind me -- this is used in the parser as a form of panic? I remember seeing some pretty bad output that resulted from using FatalError.raise() on occasion (I think rustc just failed with no output at all) -- can we not use some other method here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, if this is the "current error handling mechanism" seems fine. I'm just asking for my own edification.

Copy link
Contributor

@estebank estebank Nov 14, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It says "stop the world". The reason we aggressively removed their usages was to enable recovery and plow ahead to type checking even in the face of malformed code. It is a valid strategy to stop the world when a condition that could only have been caused by prior malformed code is met, as at that point continuing with our recovery is a liability, and we will have had errors emitted beforehand.

We might want to have a delay_span_bug as a guardrail, but this should be fine.

}
}

Expand Down
14 changes: 14 additions & 0 deletions src/test/ui/parser/issue-66357-unexpected-unreachable.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
// The problem in #66357 was that the call trace:
//
// - parse_fn_block_decl
// - expect_or
// - unexpected
// - expect_one_of
// - expected_one_of_not_found
// - recover_closing_delimiter
//
// ended up bubbling up `Ok(true)` to `unexpected` which then used `unreachable!()`.

fn f() { |[](* }
//~^ ERROR expected one of `,` or `:`, found `(`
//~| ERROR expected one of `)`, `-`, `_`, `box`, `mut`, `ref`, `|`, identifier, or path, found `*`
16 changes: 16 additions & 0 deletions src/test/ui/parser/issue-66357-unexpected-unreachable.stderr
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
error: expected one of `,` or `:`, found `(`
--> $DIR/issue-66357-unexpected-unreachable.rs:12:13
|
LL | fn f() { |[](* }
| ^ expected one of `,` or `:`

error: expected one of `)`, `-`, `_`, `box`, `mut`, `ref`, `|`, identifier, or path, found `*`
--> $DIR/issue-66357-unexpected-unreachable.rs:12:14
|
LL | fn f() { |[](* }
| -^ help: `)` may belong here
| |
| unclosed delimiter

error: aborting due to 2 previous errors