ICE in rustc_lint::unused::UnusedParens #54752
Comments
zackmdavis
added
the
I-ICE
estebank
added
the
A-lints
|
The example can be minimized to exclude #![feature(async_await)]
fn main() {
let _a = (async {});
}I should have a PR in a few minutes (despite some discomfort about apparent solutions incompletely understood). |
zackmdavis
added a commit
to zackmdavis/rust
that referenced
this issue
Oct 3, 2018
Joshua Netterfield reported an ICE when the unused-parentheses lint triggered around an async block (rust-lang#54752). In order to compose an autofixable suggestion, the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead, to preserve the formatting of the original source?—but for that, you'd have to ask the author of 5c9f806.) But then the pretty-printer panics when trying to call `<pprust::State as PrintState>::end` when `State.boxes` is empty. Empirically, the problem would seem to be solved if we start some "boxes" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style`, exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty ("pretty") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks, right?? Of course, it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof, rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today, than with certainty in some indefinite hypothetical future? Maybe the effort is worth a fifth of a shirt?? Humbly resolves rust-lang#54752.
pietroalbini
added a commit
to pietroalbini/rust
that referenced
this issue
Oct 3, 2018
…ertj abolish ICE when pretty-printing async block @jnetterf reported an ICE when the unused-parentheses lint triggered around an async block (rust-lang#54752). In order to compose an autofixable suggestion, the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead, to preserve the formatting of the original source?—but to answer that, you'd have to ask the author of 5c9f806.) But then the pretty-printer panics when trying to call `<pprust::State as PrintState>::end` when `State.boxes` is empty. Empirically, the problem would seem to be solved if we start some "boxes" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style`, exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty ("pretty") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks, right?? Of course, it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof, rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today, than with certainty in some indefinite hypothetical future? Maybe the effort is worth [a fifth of a shirt](https://hacktoberfest.digitalocean.com/stats/zackmdavis)?? Humbly resolves rust-lang#54752. r? @cramertj
pietroalbini
added a commit
to pietroalbini/rust
that referenced
this issue
Oct 4, 2018
…ertj abolish ICE when pretty-printing async block @jnetterf reported an ICE when the unused-parentheses lint triggered around an async block (rust-lang#54752). In order to compose an autofixable suggestion, the lint invokes the pretty-printer on the unnecessarily-parenthesized expression. (One wonders why the lint doesn't just use `SourceMap::span_to_snippet` instead, to preserve the formatting of the original source?—but to answer that, you'd have to ask the author of 5c9f806.) But then the pretty-printer panics when trying to call `<pprust::State as PrintState>::end` when `State.boxes` is empty. Empirically, the problem would seem to be solved if we start some "boxes" beforehand in the `ast::ExprKind::Async` arm of the big match in `print_expr_outer_attr_style`, exactly like we do in the immediately-preceding match arm for `ast::ExprKind::Block`—it would seem pretty ("pretty") reasonable for the pretty-printing of async blocks to work a lot like the pretty-printing of ordinary non-async blocks, right?? Of course, it would be shamefully cargo-culty to commit code on the basis of this kind of mere reasoning-by-analogy (in contrast to understanding the design of the pretty-printer in such detail that the correctness of the patch is comprehended with all the lucid certainty of mathematical proof, rather than being merely surmised by intuition). But maybe we care more about fixing the bug with high probability today, than with certainty in some indefinite hypothetical future? Maybe the effort is worth [a fifth of a shirt](https://hacktoberfest.digitalocean.com/stats/zackmdavis)?? Humbly resolves rust-lang#54752. r? @cramertj
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I tried compiling this code:
Note the extra set of parentheses.
My Cargo.toml had:
I expected the compiler to not crash.
Instead, it crashed with the following output:
Meta
rustc +nightly --version --verbose :
The text was updated successfully, but these errors were encountered: