fix: rhs_span to rhs_span_new

Author: cuiweixie

compiler/rustc_borrowck/src/diagnostics/mutability_errors.rs

@@ -1689,13 +1689,22 @@ fn suggest_ampmut<'tcx>(
             // If this is a usertype ascription (`let _x: &T = _y`) then pierce through it as either we want
             // to suggest `&mut` on the expression (handled here) or we return `None` and let the caller
             // suggest `&mut` on the type if the expression seems fine (e.g. `let _x: &T = &mut _y`).
+            //
+            // Note: we must use `rhs_span_new` (the span of the *inner* assignment) here, not
+            // `rhs_span` (the span of the outer re-borrow). Although current MIR lowering always
+            // assigns both statements the same source span, using the correct span is important
+            // for correctness: `rhs_str_new` is later paired with `rhs_span_new` (line below),
+            // so the snippet text must correspond to the inner span. If MIR lowering ever changes
+            // to produce different spans, using the wrong one would cause the `&` offset calculation
+            // in the suggestion below to point to the wrong source location.
+            // Regression test: `tests/ui/borrowck/suggest-ampmut-usertype-ascription.rs`
             if let Some(user_ty_projs) = body.local_decls[lhs.local].user_ty.as_ref()
                 && let [user_ty_proj] = user_ty_projs.contents.as_slice()
                 && user_ty_proj.projs.is_empty()
                 && let Either::Left(rhs_stmt_new) = body.stmt_at(*assign)
                 && let StatementKind::Assign(box (_, rvalue_new)) = &rhs_stmt_new.kind
                 && let rhs_span_new = rhs_stmt_new.source_info.span
-                && let Ok(rhs_str_new) = tcx.sess.source_map().span_to_snippet(rhs_span)
+                && let Ok(rhs_str_new) = tcx.sess.source_map().span_to_snippet(rhs_span_new)
             {
                 (rvalue, rhs_span, rhs_str) = (rvalue_new, rhs_span_new, rhs_str_new);
             }

tests/ui/borrowck/suggest-ampmut-usertype-ascription.rs

@@ -0,0 +1,51 @@
+// Regression test for the `suggest_ampmut` usertype ascription code path in borrowck.
+//
+// When a binding has a user type annotation like `let x: &T = &expr`, MIR creates
+// two statements: an inner borrow `_tmp = &expr` and an outer re-borrow `_x = &(*_tmp)`.
+// The `suggest_ampmut` function must pierce through the re-borrow to find the inner
+// assignment and use its span/snippet to produce a correct `&mut` suggestion.
+//
+// Previously there was a copy-paste bug where `span_to_snippet` was called with the
+// outer span (`rhs_span`) instead of the inner span (`rhs_span_new`). This is a latent
+// bug: current MIR lowering always assigns both statements the same source span, so the
+// diagnostic output is identical either way. However, the fix is semantically correct
+// and would prevent incorrect suggestions if MIR lowering ever produces different spans.
+//
+// This test covers the various patterns that exercise the usertype ascription path
+// to guard against regressions.
+
+fn main() {
+    // Basic usertype ascription: `let x: &T = &y`
+    // Exercises the inner-assignment pierce-through and suggests `&mut` on the expression.
+    let y = 0i32;
+    let x: &i32 = &y;
+    //~^ HELP consider changing this to be a mutable reference
+    *x = 1;
+    //~^ ERROR cannot assign to `*x`, which is behind a `&` reference
+    //~| NOTE `x` is a `&` reference, so it cannot be written to
+
+    // Usertype ascription with `&mut` on the RHS: the inner rvalue is a mutable borrow,
+    // so `suggest_ampmut` returns `ChangeBinding` and the caller suggests changing the type.
+    let mut v = Vec::new();
+    let w: &Vec<i32> = &mut v;
+    //~^ HELP consider changing this binding's type
+    w.push(1);
+    //~^ ERROR cannot borrow `*w` as mutable, as it is behind a `&` reference
+    //~| NOTE `w` is a `&` reference, so it cannot be borrowed as mutable
+
+    // Usertype ascription with parenthesized expression.
+    let a = 0i32;
+    let b: &i32 = &(a);
+    //~^ HELP consider changing this to be a mutable reference
+    *b = 2;
+    //~^ ERROR cannot assign to `*b`, which is behind a `&` reference
+    //~| NOTE `b` is a `&` reference, so it cannot be written to
+
+    // Usertype ascription inside a block expression.
+    let c = 0i32;
+    let d: &i32 = { &c };
+    //~^ HELP consider changing this to be a mutable reference
+    *d = 3;
+    //~^ ERROR cannot assign to `*d`, which is behind a `&` reference
+    //~| NOTE `d` is a `&` reference, so it cannot be written to
+}

tests/ui/borrowck/suggest-ampmut-usertype-ascription.stderr

@@ -0,0 +1,48 @@
+error[E0594]: cannot assign to `*x`, which is behind a `&` reference
+  --> $DIR/suggest-ampmut-usertype-ascription.rs:23:5
+   |
+LL |     *x = 1;
+   |     ^^^^^^ `x` is a `&` reference, so it cannot be written to
+   |
+help: consider changing this to be a mutable reference
+   |
+LL |     let x: &i32 = &mut y;
+   |                    +++
+
+error[E0596]: cannot borrow `*w` as mutable, as it is behind a `&` reference
+  --> $DIR/suggest-ampmut-usertype-ascription.rs:32:5
+   |
+LL |     w.push(1);
+   |     ^ `w` is a `&` reference, so it cannot be borrowed as mutable
+   |
+help: consider changing this binding's type
+   |
+LL |     let w: &mut Vec<i32> = &mut v;
+   |             +++
+
+error[E0594]: cannot assign to `*b`, which is behind a `&` reference
+  --> $DIR/suggest-ampmut-usertype-ascription.rs:40:5
+   |
+LL |     *b = 2;
+   |     ^^^^^^ `b` is a `&` reference, so it cannot be written to
+   |
+help: consider changing this to be a mutable reference
+   |
+LL |     let b: &i32 = &mut (a);
+   |                    +++
+
+error[E0594]: cannot assign to `*d`, which is behind a `&` reference
+  --> $DIR/suggest-ampmut-usertype-ascription.rs:48:5
+   |
+LL |     *d = 3;
+   |     ^^^^^^ `d` is a `&` reference, so it cannot be written to
+   |
+help: consider changing this to be a mutable reference
+   |
+LL |     let d: &i32 = { &mut c };
+   |                      +++
+
+error: aborting due to 4 previous errors
+
+Some errors have detailed explanations: E0594, E0596.
+For more information about an error, try `rustc --explain E0594`.