ICE: broken MIR in CoroutineKindShim
#129074
Assignees
Labels
C-bug
Category: This is a bug.
F-async_closure
`#![feature(async_closure)]`
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
matthiaskrgr
added
I-ICE
rustbot
added
needs-triage
|
With this full minimization: // flags: -Zvalidate-mir
#![feature(async_closure)]
fn hello(x: &Ty) {
let c = async || {
x.hello();
};
}
struct Ty;
impl Ty {
fn hello(self) {}
}
fn main() {}The real blame commit is: #123349 |
compiler-errors
removed
the
needs-triage
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
Aug 15, 2024
…-ref, r=lcnr Fix projections when parent capture is by-ref but child capture is by-value in the `ByMoveBody` pass This fixes a somewhat strange bug where we build the incorrect MIR in rust-lang#129074. This one is weird, but I don't expect it to actually matter in practice since it almost certainly results in a move error in borrowck. However, let's not ICE. Given the code: ``` #![feature(async_closure)] // NOT copy. struct Ty; fn hello(x: &Ty) { let c = async || { *x; //~^ ERROR cannot move out of `*x` which is behind a shared reference }; } fn main() {} ``` The parent coroutine-closure captures `x: &Ty` by-ref, resulting in an upvar of `&&Ty`. The child coroutine captures `x` by-value, resulting in an upvar of `&Ty`. When constructing the by-move body for the coroutine-closure, we weren't applying an additional deref projection to convert the parent capture into the child capture, resulting in an type error in assignment, which is a validation ICE. As I said above, this only occurs (AFAICT) in code that eventually results in an error, because it is only triggered by HIR that attempts to move a non-copy value out of a ref. This doesn't occur if `Ty` is `Copy`, since we'd instead capture `x` by-ref in the child coroutine. Fixes rust-lang#129074
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Aug 15, 2024
Rollup merge of rust-lang#129101 - compiler-errors:deref-on-parent-by-ref, r=lcnr Fix projections when parent capture is by-ref but child capture is by-value in the `ByMoveBody` pass This fixes a somewhat strange bug where we build the incorrect MIR in rust-lang#129074. This one is weird, but I don't expect it to actually matter in practice since it almost certainly results in a move error in borrowck. However, let's not ICE. Given the code: ``` #![feature(async_closure)] // NOT copy. struct Ty; fn hello(x: &Ty) { let c = async || { *x; //~^ ERROR cannot move out of `*x` which is behind a shared reference }; } fn main() {} ``` The parent coroutine-closure captures `x: &Ty` by-ref, resulting in an upvar of `&&Ty`. The child coroutine captures `x` by-value, resulting in an upvar of `&Ty`. When constructing the by-move body for the coroutine-closure, we weren't applying an additional deref projection to convert the parent capture into the child capture, resulting in an type error in assignment, which is a validation ICE. As I said above, this only occurs (AFAICT) in code that eventually results in an error, because it is only triggered by HIR that attempts to move a non-copy value out of a ref. This doesn't occur if `Ty` is `Copy`, since we'd instead capture `x` by-ref in the child coroutine. Fixes rust-lang#129074
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
auto-reduced (treereduce-rust):
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustc -Zvalidate-mir --edition=2018Program output
@rustbot label +F-async_closure
The text was updated successfully, but these errors were encountered: