-
Notifications
You must be signed in to change notification settings - Fork 13.4k
ice: continue to unknown label
async fn / assertion failed: ln.index() < self.live_nodes
#113379
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
Comments
Regression in nightly-2020-02-16 |
Not async related: fn f() -> impl Sized {
'b: {
continue 'b;
}
} This is another one of those problems that has to do with checking the type of an opaque too early, which means calling |
Oh weird I thought I removed the async and it made the ICE into an error :| |
No big deal, just figured out a more minimal repro while looking at the call stack + being familiar with this class of issues. It still needs to return an |
Another one: trait Trait<const S: &'static str> {}
struct Bug<T>
where
T: Trait<
{
'b: {
continue 'b;
}
},
>,
{
t: T,
} |
continue to unknown label
async fn continue to unknown label
async fn / assertion failed: ln.index() < self.live_nodes
update as of all the error handling refactoring: auto-reduced (treereduce-rust): async fn f999() -> Vec<usize> {
'b: {
continue 'b;
}
}
original: async fn f999() -> Vec<usize> {
'b: {
continue 'b;
}
} Version information
Command: Program output
|
@rustbot claim |
Rollup merge of rust-lang#141317 - dianne:continue-liveness-ice-fix, r=compiler-errors typeck: catch `continue`s pointing to blocks This taints the typeck results with errors if a `continue` is found not pointing to a loop. A few things were going wrong here. First, since this wasn't caught in typeck, we'd end up building the THIR and then running liveness lints on ill-formed HIR. Since liveness assumes all `continue`s point to loops, it wasn't setting a live node for the `continue`'s destination. There was a fallback for if it couldn't retrieve that live node, but it was faulty; it would create a new live node to represent an erroneous state after the analysis's RWU table had already been built. This would ICE if the new live node was used in operations, such as merging results from the arms of a match. I've removed this error-recovery since it was buggy, and we should really catch bad labels before liveness. I've also replaced an outdated comment about when liveness lints are run. At this point, I think the call to `check_liveness` could be moved elsewhere, but if it can be run when the typeck results are tainted by errors, it'll need some slight refactoring so it can bail out in that case. In lieu of that, I've added an assert. Fixes rust-lang#113379 Fixes rust-lang#121623
Uh oh!
There was an error while loading. Please reload this page.
Code
Meta
rustc --version --verbose
:Error output
Backtrace
The text was updated successfully, but these errors were encountered: