`rustc` should suggest borrowing values, when a borrow satisfies the same trait bound as an owned value

[pluiedev]

On the Rust community Discord server, a user reported that functions like std::fs::create_dir_all, that take either PathBufs or &PathBufs thanks to their T: AsRef<Path> bound, do not make clear to the user that the function does not require an owned value.

It is obviously too late to change the signatures on the freestanding functions in std::fs to prevent users from encountering this issue, so we really need to improve the error generated by this issue, which does not mention borrowing the value as a solution.

---

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=83da9a037a3b29b8f28c341fbb725787

pub fn create_dir_and_return_path() -> std::path::PathBuf {
    let path = std::path::PathBuf::from("haha");
    std::fs::create_dir_all(path).unwrap();
    path
}

The current output is:

Compiling playground v0.0.1 (/playground)
error[[E0382]](https://doc.rust-lang.org/nightly/error-index.html#E0382): use of moved value: `path`
 --> src/lib.rs:4:5
  |
2 |     let path = std::path::PathBuf::from("haha");
  |         ---- move occurs because `path` has type `PathBuf`, which does not implement the `Copy` trait
3 |     std::fs::create_dir_all(path).unwrap();
  |                             ---- value moved here
4 |     path
  |     ^^^^ value used here after move

For more information about this error, try `rustc --explain E0382`.
error: could not compile `playground` due to previous error

Ideally the output should look like:

Compiling playground v0.0.1 (/playground)
error[[E0382]](https://doc.rust-lang.org/nightly/error-index.html#E0382): use of moved value: `path`
 --> src/lib.rs:4:5
  |
2 |     let path = std::path::PathBuf::from("haha");
  |         ---- move occurs because `path` has type `PathBuf`, which does not implement the `Copy` trait
3 |     std::fs::create_dir_all(path).unwrap();
  |                             ---- value moved here
4 |     path
  |     ^^^^ value used here after move
  |
  = help: consider borrowing `path` here:
  |
3 -    std::fs::create_dir_all(path).unwrap();
3 +    std::fs::create_dir_all(&path).unwrap();
  |
  = note: ...so that `path` can remain valid after function call


For more information about this error, try `rustc --explain E0382`.
error: could not compile `playground` due to previous error

[mejrs]

IMO the compile errors related to Copy are not that great, and most of them could use an overhaul. Maybe it is worth addressing these on a higher level?

[BGR360]

@mejrs Can you point out more of the ways in which they are not that great? So that a wanting contributor could try to formulate a higher-level approach?

[mejrs]

@mejrs Can you point out more of the ways in which they are not that great? So that a wanting contributor could try to formulate a higher-level approach?

At the time this was posted we had a small discussion on discord...and I think the main issue with it is that the error message has a lot of focus on "this doesn't implement Copy". When this error comes up a lot of newbies seem to assume they can fix it by implementing Copy, which they obviously can't for things like String or PathBuf.

[BGR360]

Okay. So perhaps we could change "does not implement the Copy trait" to say "cannot be trivially copied" and only suggest "try implementing the Copy trait" if the type is local?

But this does not address the problem raised by this issue still, right?

So to go further, for foreign types, we could suggest .clone() if the type is Clone, and/or suggest & if the function can also be invoked with a reference.

Thoughts?

[mejrs]

Well, I hadn't really thought about it that much. I was/am planning to make a proper discussion/a PR once I have some concrete ideas. I am thinking something along the lines of

2 |     let path = std::path::PathBuf::from("haha");
  |         ---- binding `path` is initialized here
3 |     std::fs::create_dir_all(path).unwrap();
  |                             ---- `Because type `PathBuf` does not implement the
                              `Copy` trait, binding `path` is invalidated when it is
                             moved into function `create_dir_all`
4 |     path
  |     ^^^^ invalid value later used here

In my experience explaining Copy and moving and copying in terms of the binding remaining valid or getting invalidated works quite well, so I'd rather nudge newbies towards thinking "can i avoid invalidating path?"