Description
Spawned off of #45142
Consider the following code (play):
struct Events<R>(R);
struct Other;
pub trait Trait<T> {
fn handle(value: T) -> Self;
}
// Blanket impl. (If you comment this out, compiler figures out that it
// is passing an `&mut` to a method that must be expecting an `&mut`,
// and injects an auto-reborrow.)
impl<T, U> Trait<U> for T where T: From<U> {
fn handle(_: U) -> Self { unimplemented!() }
}
impl<'a, R> Trait<&'a mut Events<R>> for Other {
fn handle(_: &'a mut Events<R>) -> Self { unimplemented!() }
}
fn this_compiles<'a, R>(value: &'a mut Events<R>) {
for _ in 0..3 {
Other::handle(&mut *value);
}
}
fn this_does_not<'a, R>(value: &'a mut Events<R>) {
for _ in 0..3 {
Other::handle( value);
}
}
fn main() {}
Today, this yields the diagnostic:
error[E0382]: use of moved value: `value`
--> src/main.rs:30:29
|
28 | fn this_does_not<'a, R>(value: &'a mut Events<R>) {
| ----- move occurs because `value` has type `&mut Events<R>`, which does not implement the `Copy` trait
29 | for _ in 0..3 {
30 | Other::handle( value);
| ^^^^^ value moved here, in previous iteration of loop
We could do better. For example, the diagnostic could additionally say:
consider writing `Other::handle(&mut *value)` to create a fresh reborrow of `value`.
Background:
The compiler tries hard to auto-inject &mut
-reborrows when it makes sense; as a way to create a fresh &mut
reference to pass into the method invocation, and avoid moving the pre-existing &mut
reference.
But there are times, often involving generic code, when it cannot automatically inject a reborrow. (After all, there are cases where the intent is to move the borrow into some place whose dynamic extent outlives that of the method invocation itself; and the static analysis cannot tell if this was the case at the point where it is deciding whether to insert an &mut
-reborrow or not.)
This can lead to a diagnostic for the user telling them that they have a used of a moved value.
But new-comers to Rust do not always know about the option of putting in a &mut
-reborrow themselves.
Our diagnostics could help them here. Even though we choose to not attempt to auto-inject the auto-reborrow in the compiler itself, our diagnostics have enough information about the method signature and the invocation to suggest to the user that they write out the &mut *value
themselves.