Change:
} match expr.kind { <del> hir::ExprKind::Index(ref base_expr, ref index_expr) => { // We need to get the final type in case dereferences were needed for the trait // to apply (#72002). let index_expr_ty = self.typeck_results.borrow().expr_ty_adjusted(index_expr); self.convert_place_op_to_mutable( PlaceOp::Index, expr, base_expr, &[index_expr_ty], ); </del> <ins> hir::ExprKind::Index(ref base_expr, ..) => { self.convert_place_op_to_mutable(PlaceOp::Index, expr, base_expr); </ins> } hir::ExprKind::Unary(hir::UnOp::UnDeref, ref base_expr) => { <del> self.convert_place_op_to_mutable(PlaceOp::Deref, expr, base_expr, &[]); </del> <ins> self.convert_place_op_to_mutable(PlaceOp::Deref, expr, base_expr); </ins> } _ => {} }

Discussion:
I tried to compile this code: I expected the code to compile Instead, it failed to compile with this lifetime error: If I change the function in these ways it compiles. This compiles successfully on Stable Rust 1.45.0 back to 1.26.0 (when lifetimes were stabilized) This fails to compile on these versions(haven't tried previous ones in the same channels): 1.46.0-beta.2 (2020-07-23 ) 1.47.0-nightly (2020-07-28 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Let’s find the culprit for this. ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Assigning as and removing .
Regressed in which is a roll-up, likely
cc in case you want to fix this is a follow-up of
The explicit lifetimes are edit: the lt of doesn't matter
assigning to but they will probably need to delegate as there time is limited in near future.
Will look into this today. claim
This code compiles in Rust 1.17 but not in Rust 1.18+: unifies DerefMut/IndexMut to use the "fix-up" path originally used when performing method calls, so it broadens the bug to assignments as well.
Okay, this is an issue near convertplaceoptomutable. Just re-infer the index type and re-do the coercion is sufficient to fix the regionck failure (). However I am not sure why the existing code does not work. This piece of code is last touched in . cc do you have any clue why the existing approach does not work well with regionck?
Hmm.. I would not have expected that code to have to change, since the failure seems to try to make the anonymous lifetime on in the method match , which it should not. I think your patch is sound, but touching the "wrong" thing.

Basically now we are creating new lifetimes for the index, when I would have thought that the container type's reference's lifetime needs adjustment. So looking at , I'm guessing is taking the wrong region and should instead invent a new one?
This issue is not related to anonymous lifetime actually, if you spell out the lifetime explicitly it's still the same. The root cause has been identified and that line actually is the culprit, a detailed analysis can be found in .
I a couple of examples of workarounds that allowed the function to compile, with the same signature.