Change:
} } <ins> let prev_pessimistic = visitor.pessimistic_yield; // Ordinarily, we can rely on the visit order of HIR intravisit // to correspond to the actual execution order of statements. // However, there's a weird corner case with compund assignment // operators (e.g. `a += b`). The evaluation order depends on whether // or not the operator is overloaded (e.g. whether or not a trait // like AddAssign is implemented). // For primitive types (which, despite having a trait impl, don't actually // end up calling it), the evluation order is right-to-left. For example, // the following code snippet: // //    let y = &mut 0; //    *{println!("LHS!"); y} += {println!("RHS!"); 1}; // // will print: // // RHS! // LHS! // // However, if the operator is used on a non-primitive type, // the evaluation order will be left-to-right, since the operator // actually get desugared to a method call. For example, this // nearly identical code snippet: // //     let y = &mut String::new(); //    *{println!("LHS String"); y} += {println!("RHS String"); "hi"}; // // will print: // LHS String // RHS String // // To determine the actual execution order, we need to perform // trait resolution. Unfortunately, we need to be able to compute // yield_in_scope before type checking is even done, as it gets // used by AST borrowcheck. // // Fortunately, we don't need to know the actual execution order. // It suffices to know the 'worst case' order with respect to yields. // Specifically, we need to know the highest 'expr_and_pat_count' // that we could assign to the yield expression. To do this, // we pick the greater of the two values from the left-hand // and right-hand expressions. This makes us overly conservative // about what types could possibly live across yield points, // but we will never fail to detect that a type does actually // live across a yield point. The latter part is critical - // we're already overly conservative about what types will live // across yield points, as the generated MIR will determine // when things are actually live. However, for typecheck to work // properly, we can't miss any types. </ins> match expr.node { // Manually recurse over closures, because they are the only // case of nested bodies that share the parent environment. hir::ExprKind::Closure(.., body, _, _) => { let body = visitor.tcx.hir().body(body); visitor.visit_body(body); <ins> }, hir::ExprKind::AssignOp(_, ref left_expr, ref right_expr) => { debug!("resolve_expr - enabling pessimistic_yield, was previously {}", prev_pessimistic); let start_point = visitor.fixup_scopes.len(); visitor.pessimistic_yield = true; // If the actual execution order turns out to be right-to-left, // then we're fine. However, if the actual execution order is left-to-right, // then we'll assign too low a count to any `yield` expressions // we encounter in 'right_expression' - they should really occur after all of the // expressions in 'left_expression'. visitor.visit_expr(&right_expr); visitor.pessimistic_yield = prev_pessimistic; debug!("resolve_expr - restoring pessimistic_yield to {}", prev_pessimistic); visitor.visit_expr(&left_expr); debug!("resolve_expr - fixing up counts to {}", visitor.expr_and_pat_count); // Remove and process any scopes pushed by the visitor let target_scopes = visitor.fixup_scopes.drain(start_point..); for scope in target_scopes { let mut yield_data = visitor.scope_tree.yield_in_scope.get_mut(&scope).unwrap(); let count = yield_data.expr_and_pat_count; let span = yield_data.span; // expr_and_pat_count never decreases. Since we recorded counts in yield_in_scope // before walking the left-hand side, it should be impossible for the recorded // count to be greater than the left-hand side count. if count > visitor.expr_and_pat_count { bug!("Encountered greater count {} at span {:?} - expected no greater than {}", count, span, visitor.expr_and_pat_count); } let new_count = visitor.expr_and_pat_count; debug!("resolve_expr - increasing count for scope {:?} from {} to {} at span {:?}", scope, count, new_count, span); yield_data.expr_and_pat_count = new_count; } </ins> } _ => intravisit::walk_expr(visitor, expr)

Discussion:
The code below causes an internal compiler error. I've provided some more details as comments. rustc 1.37.0-nightly ( 2019-05-31) binary: rustc commit-hash: commit-date: 2019-05-31 host: x86_64-unknown-linux-gnu release: 1.37.0-nightly LLVM version: 8.0 Backtrace:
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 line to occur.
minimized:
Marking as blocking -- not entirely clear how general this is but it looks like something people might run across fairly easily.
cc -- maybe you have some idea what the problem is here?
My guess is that implicitly borrows during the type checking phase, so we don't record as being part of the generator.
This seems to be related to the field calculated . When , a computed count of gets compared against a exprcount of , resulting in being set to . However,I'm seeing this line earlier in the logs: which has a count of , as expected. This would seem to suggest that the count is somehow getting overwritten later on.
On further inspection, the count doesn't appear to be getting overwritten. and are both computing it in the same way, but it seems inconsistent with the MIR that ultimately gets generated. I think that due to the way the HIR post-order traversal works, the overall assignment expression is computed to be 'after' the inner , which is interpreted to mean that it isn't live over the yield point. However, consider the MIR for a similar function: The relevant MIR is; Here, the mutable borrow adjustment occurs before the body of the block. When the block includes a , the is clearly live across the yield point.