-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Broken MIR in futures generator (async/await) #61442
Comments
Does this issue still occur? I couldn't reproduce it from given code on playground. |
I just checked with nightly 2019-06-03, and it's still there. It requires the |
minimized: #![feature(generators)]
fn foo() {
let x = static || {
let mut s = String::new();
s += { yield; "" };
};
}
fn main() {
foo()
} |
Marking as blocking -- not entirely clear how general this is but it looks like something people might run across fairly easily. |
cc @Zoxc -- maybe you have some idea what the problem is here? |
My guess is that |
This seems to be related to the However,I'm seeing this line earlier in the logs:
which has a count of |
On further inspection, the count doesn't appear to be getting overwritten. I think that due to the way the HIR post-order traversal works, the overall assignment expression However, consider the MIR for a similar function: fn main() {
let mut a = String::new();
a += { let b = "Hello"; b };
} The relevant MIR is;
Here, the mutable borrow adjustment |
Fixes rust-lang#61442 When rustc::middle::region::ScopeTree ccomputes its yield_in_scope field, it relies on the HIR visitor order to properly compute which types must be live across yield points. In order for the computed scopes to agree with the generated MIR, we must ensure that expressions evaluated before a yield point are visited before the 'yield' expression. However, the visitor order for ExprKind::AssignOp was incorrect. The left-hand side of a compund assignment expression is evaluated before the right-hand side, but the right-hand expression was being visited before the left-hand expression. If the left-hand expression caused a new type to be introduced (e.g. through a deref-coercion), the new type would be incorrectly seen as occuring *after* the yield point, instead of before. This leads to a mismatch between the computed generator types and the MIR, since the MIR will correctly see the type as being live across the yield point. To fix this, we correct the visitor order for ExprKind::AssignOp to reflect the actual evaulation order.
Fix HIR visit order Fixes #61442 When rustc::middle::region::ScopeTree computes its yield_in_scope field, it relies on the HIR visitor order to properly compute which types must be live across yield points. In order for the computed scopes to agree with the generated MIR, we must ensure that expressions evaluated before a yield point are visited before the 'yield' expression. However, the visitor order for ExprKind::AssignOp was incorrect. The left-hand side of a compund assignment expression is evaluated before the right-hand side, but the right-hand expression was being visited before the left-hand expression. If the left-hand expression caused a new type to be introduced (e.g. through a deref-coercion), the new type would be incorrectly seen as occuring *after* the yield point, instead of before. This leads to a mismatch between the computed generator types and the MIR, since the MIR will correctly see the type as being live across the yield point. To fix this, we correct the visitor order for ExprKind::AssignOp to reflect the actual evaulation order.
Issue
The code below causes an internal compiler error. I've provided some more details as comments.
Code
Meta
rustc 1.37.0-nightly (7840a0b 2019-05-31)
binary: rustc
commit-hash: 7840a0b
commit-date: 2019-05-31
host: x86_64-unknown-linux-gnu
release: 1.37.0-nightly
LLVM version: 8.0
Backtrace:
The text was updated successfully, but these errors were encountered: