Fix fn front matter parsing ICE from invalid code. #60132
Conversation
This commit fixes an "unreachable code" ICE that results from parsing invalid code where the compiler is expecting the next trait item declaration in the middle of the previous trait item due to extra closing braces.
rust-highfive
added
the
S-waiting-on-review
| // `self.expected_tokens`, therefore, do not use `self.unexpected()` which doesn't | ||
| // account for this. | ||
| if !self.expect_one_of(&[], &[])? { unreachable!() } | ||
| } |
There was a problem hiding this comment.
Although I think this change will fix the general problem today, I feel we could also address the side of the recovery code as well to not attempt to close the block when encountering an incorrect closing delimiter. It is tricky because what is best to do depends entirely on the type of mistake made and we don't do global analysis...
What do you think? Should we have a follow up PR/ticket with different common cases to test the recovery mechanism?
There was a problem hiding this comment.
I’d land this as is to fix the ICE, but I think a follow up to try and handle this case more gracefully definitely makes sense.
I spent a bunch of time trying to work out a nice way to recover from this case but I couldn’t see one. If we don’t attempt to close the block when encountering an unclosed delimiter then that’ll regress other cases that we recover from currently, it’s a tough one.
|
@bors r+ rollup |
|
📌 Commit 60c6ed9 has been approved by |
bors
added
S-waiting-on-bors
Fix fn front matter parsing ICE from invalid code. Fixes #60075. This PR fixes an "unreachable code" ICE that results from parsing invalid code where the compiler is expecting the next trait item declaration in the middle of the previous trait item due to extra closing braces. r? @estebank (thanks for the minimized test case)
|
☀️ Test successful - checks-travis, status-appveyor |
Fixes #60075.
This PR fixes an "unreachable code" ICE that results from parsing
invalid code where the compiler is expecting the next trait item
declaration in the middle of the previous trait item due to extra
closing braces.
r? @estebank (thanks for the minimized test case)