Unhelpful lifetime error on .clone() refers to &&T, could suggest adding Clone

[kw217]

In code that works with boxed closures (e.g., futures code), it is common to clone an argument so that it can be moved into the closure. If the argument is passed by reference, clone() will clone the value if there is a Clone implementation, otherwise it will pointlessly clone the reference.

If the Clone implementation is not present, rustc reports E0495 quite unhelpfully.

Please could rustc spot this and suggest adding a Clone implementation? I think the signature is an invocation of clone() at &T when the type compatibility being checked is &&T.

Example:

// Uncomment the derive to make this compile.
//#[derive(Clone)]
struct Foo(String);

fn bar(p: &Foo) -> Box<Fn() -> ()> {
    let p = p.clone();
    let f = move || baz(&p);
    Box::new(f)
}

fn baz(_: &Foo) {}

pub fn main() {
    let foo = Foo("foo".to_string());
    let closure = bar(&foo);
    closure()
}

Error message:

error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements
 --> doubleref.rs:5:15
  |
5 |     let p = p.clone();
  |               ^^^^^
  |
note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the body at 4:35...
 --> doubleref.rs:4:36
  |
4 |   fn bar(p: &Foo) -> Box<Fn() -> ()> {
  |  ____________________________________^ starting here...
5 | |     let p = p.clone();
6 | |     let f = move || baz(&p);
7 | |     Box::new(f)
8 | | }
  | |_^ ...ending here
note: ...so that types are compatible (expected &&Foo, found &&Foo)
 --> doubleref.rs:5:15
  |
5 |     let p = p.clone();
  |               ^^^^^
  = note: but, the lifetime must be valid for the static lifetime...
note: ...so that the type `[closure@doubleref.rs:6:13: 6:28 p:&Foo]` will meet its required lifetime bounds
 --> doubleref.rs:7:5
  |
7 |     Box::new(f)
  |     ^^^^^^^^^^^

[kw217]

Hi - do you need any further information for triage?

[steveklabnik]

Triage: the error has changed slightly:

error[E0621]: explicit lifetime required in the type of `p`
 --> src/main.rs:7:5
  |
4 | fn bar(p: &Foo) -> Box<Fn() -> ()> {
  |           ---- help: add explicit lifetime `'static` to the type of `p`: `&'static Foo`
...
7 |     Box::new(f)
  |     ^^^^^^^^^^^ lifetime `'static` required

error: aborting due to previous error

[Dylan-DPC]

Current error:

error: lifetime may not live long enough
 --> src/main.rs:6:5
  |
3 | fn bar(p: &Foo) -> Box<dyn Fn() -> ()> {
  |           - let's call the lifetime of this reference `'1`
...
6 |     Box::new(f)
  |     ^^^^^^^^^^^ returning this value requires that `'1` must outlive `'static`
  |
help: to declare that the trait object captures data from argument `p`, you can add an explicit `'_` lifetime bound
  |
3 | fn bar(p: &Foo) -> Box<dyn Fn() -> () + '_> {
  |                                       ++++

[estebank]

After applying the suggestion mentioned above, the output is

warning: call to `.clone()` on a reference in this situation does nothing
 --> src/main.rs:6:14
  |
6 |     let p = p.clone();
  |              ^^^^^^^^ help: remove this redundant call
  |
  = note: the type `Foo` does not implement `Clone`, so calling `clone` on `&Foo` copies the reference, which does not do anything and can be removed
  = note: `#[warn(noop_method_call)]` on by default

Potentially the lint should mention #[derive(Clone)] as an option.

I believe that the direction the suggestions take us is perfectly valid given the available constraints (it makes sense to lead people towards borrowing more than cloning).

[estebank]

The only thing left after #121471 is to mention T: !Clone in the lifetime error. Beyond that, we already provide enough information for people to get from this case to proper understanding what's going on (but not in one step).