Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: In case it helps, when using the stable toolchain, the compiler does not panic but instead emits this error: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bisected to . CC searched nightlies: from nightly-2021-10-01 to nightly-2021-11-25 regressed nightly: nightly-2021-11-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details label regression-from-stable-to-nightly
I can fix this quickly -- seems like just changing an to a since the can be out of bounds. claim
(only tangentially related) I also noticed a regression in error spans between stable and beta... stable: beta:
That was an intentional change, meant to highlight the fact that the attempted mutable borrow is occurring because of the method call. However, it seems to be confusing for a lot of people, so I'll look into improving it.
Ah thanks for letting me know. Maybe we can split the span up into the receiver and the method, and add a note on the latter like "due to this method which takes &mut self". Not sure if that much info bubbles down into borrowck. I'd be interested in making that change if you've got a lot on your plate and it's (relatively) easy to do.
See for discussion about this exact idea. It'd be nice, but likely hard to implement.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high

Discussion:
// check if the RHS is from desugaring let opt_assignment_rhs_span = self.body.find_assignments(local).first().map(|&location| { <del> let stmt = &self.body[location.block].statements [location.statement_index]; match stmt.kind { mir::StatementKind::Assign(box ( _, mir::Rvalue::Use(mir::Operand::Copy(place)), )) => { self.body.local_decls[place.local].source_info.span } _ => self.body.source_info(location).span, </del> <ins> if let Some(mir::Statement { source_info: _, kind: mir::StatementKind::Assign(box ( _, mir::Rvalue::Use(mir::Operand::Copy(place)), )), }) = self.body[location.block] .statements .get(location.statement_index) { self.body.local_decls[place.local].source_info.span } else { self.body.source_info(location).span </ins> } }); match opt_assignment_rhs_span.and_then(|s| s.desugaring_kind()) {

<ins> struct TestClient; impl TestClient { fn get_inner_ref(&self) -> &Vec<usize> { todo!() } } fn main() { let client = TestClient; let inner = client.get_inner_ref(); //~^ HELP consider changing this to be a mutable reference inner.clear(); //~^ ERROR cannot borrow `*inner` as mutable, as it is behind a `&` reference [E0596] } </ins>

<ins> error[E0596]: cannot borrow `*inner` as mutable, as it is behind a `&` reference --> $DIR/issue-91206.rs:13:5 | LL |     let inner = client.get_inner_ref(); |         ----- help: consider changing this to be a mutable reference: `&mut Vec<usize>` LL | LL |     inner.clear(); |     ^^^^^^^^^^^^^ `inner` is a `&` reference, so the data it refers to cannot be borrowed as mutable error: aborting due to previous error For more information about this error, try `rustc --explain E0596`. </ins>