-
Notifications
You must be signed in to change notification settings - Fork 13k
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.
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
Always emit unclosed delimiter diagnostics #58903
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
@estebank Does this regression exist on the current beta compiler? If so we should beta backport. |
@Centril I thought beta was spared, but alas, it wasn't. |
@estebank Aw; crap... 😭; At least we caught it before it went to stable 🎉! |
This comment has been minimized.
This comment has been minimized.
5d4334c
to
163191a
Compare
This comment has been minimized.
This comment has been minimized.
163191a
to
a3da7da
Compare
2efe0a8
to
fdde883
Compare
This comment has been minimized.
This comment has been minimized.
fdde883
to
cc077bc
Compare
@bors r+ |
📌 Commit cc077bcd2f625101eee450c0e0083210d2e51af1 has been approved by |
@bors p=52 |
cc077bc
to
551ea65
Compare
@petrochenkov subsuming #58863 into this PR to avoid merge conflict. |
@bors r=petrochenkov |
📌 Commit 551ea65 has been approved by |
LL | } | ||
| - expected one of 11 possible tokens here | ||
LL | } | ||
| ^ unexpected token |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Finally identified what is causing these: when reaching the end of the current TokenTree
, self.bump()
will advance to a close token corresponding to the opening delimiter. There are two options: 1) attempt to rewrite the TokenTree
representation that the Parser
has once we suggest a close delim (high potential for bad lurking bugs), or 2) catch this specific case in expect_one_of
, but that might be too magical.
@bors p=2 |
Always emit unclosed delimiter diagnostics Fix #58886.
☀️ Test successful - checks-travis, status-appveyor |
discussed at T-compiler meeting. beta-accepted. |
…i-obk Don't fatal when calling `expect_one_of` when recovering arg in `parse_seq` In `parse_seq`, when parsing a sequence of token-separated items, if we don't see a separator, we try to parse another item eagerly in order to give a good diagnostic and recover from a missing separator: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L900-L901 If parsing the item itself calls `expect_one_of`, then we will fatal because of rust-lang#58903: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L513-L516 For `precise_capturing` feature I implemented, we do end up calling `expected_one_of`: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/ty.rs#L712-L714 This leads the compiler to fatal *before* having emitted the first error, leading to absolutely no useful information for the user about what happened in the parser. This PR makes it so that we stop doing that. Fixes rust-lang#124195
…i-obk Don't fatal when calling `expect_one_of` when recovering arg in `parse_seq` In `parse_seq`, when parsing a sequence of token-separated items, if we don't see a separator, we try to parse another item eagerly in order to give a good diagnostic and recover from a missing separator: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L900-L901 If parsing the item itself calls `expect_one_of`, then we will fatal because of rust-lang#58903: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L513-L516 For `precise_capturing` feature I implemented, we do end up calling `expected_one_of`: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/ty.rs#L712-L714 This leads the compiler to fatal *before* having emitted the first error, leading to absolutely no useful information for the user about what happened in the parser. This PR makes it so that we stop doing that. Fixes rust-lang#124195
Rollup merge of rust-lang#124169 - compiler-errors:parser-fatal, r=oli-obk Don't fatal when calling `expect_one_of` when recovering arg in `parse_seq` In `parse_seq`, when parsing a sequence of token-separated items, if we don't see a separator, we try to parse another item eagerly in order to give a good diagnostic and recover from a missing separator: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L900-L901 If parsing the item itself calls `expect_one_of`, then we will fatal because of rust-lang#58903: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/mod.rs#L513-L516 For `precise_capturing` feature I implemented, we do end up calling `expected_one_of`: https://github.com/rust-lang/rust/blob/d1a0fa5ed3ffe52d72f761d3c95cbeb0a9cdfe66/compiler/rustc_parse/src/parser/ty.rs#L712-L714 This leads the compiler to fatal *before* having emitted the first error, leading to absolutely no useful information for the user about what happened in the parser. This PR makes it so that we stop doing that. Fixes rust-lang#124195
Fix #58886.