-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Unhelpful suggestions on reference mutability #134467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Note that there is a warning for this, but it is unfortunately not shown as long as the code has errors. If you remove the warning: call to `.clone()` on a reference in this situation does nothing
--> src/main.rs:47:25
|
47 | let mut crabs = data.clone();
| ^^^^^^^^
|
= note: the type `Vec<Ferris>` does not implement `Clone`, so calling `clone` on `&Vec<Ferris>` copies the reference, which does not do anything and can be removed
= note: `#[warn(noop_method_call)]` on by default
help: remove this redundant call
|
47 - let mut crabs = data.clone();
47 + let mut crabs = data;
|
help: if you meant to clone `Vec<Ferris>`, implement `Clone` for it
--> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/vec/mod.rs:397:1
|
397+ #[derive(Clone)]
398| pub struct Vec<T, #[unstable(feature = "allocator_api", issue = "32838")] A: Allocator = Global> {
| is shown, which hints at the solution (though the location is currently wrong, which is reported in #134471). |
Thanks for the quick triage!
Apologies in advance, dissecting this a bit further in terms of both errors as in mistakes and errors as in compiler output 🙇♂ Unfortunately, even the "correct code" for the I think this is the core of this issue report: the warning on useless clone needs a big bump in priority, as it can be the likely root cause of issues, including seemingly more severe errors. Perhaps it should always be shown, even when other errors are present. I'm even pondering if it should be promoted into an error (perhaps a rustc lint that can be optionally allowed if needed), or otherwise highlighted further. Temporarily removing the mutable method call in order to remove the error (as in make it pass compilation) might make the warning visible. I don't think this is enough though, and we should improve the user experience here. Removing the call that requires mutability is extremely unlikely to be a debugging step done by the user, when using the mutable method is exactly the thing they are trying to do. I hope this doesn't come off as hostile - I just want to point out more details from the user experience side. Providing this warning only when the code no longer has errors is likely to be too late - the user might not get there without it! |
Just noticed that this problem that the lint doesn't run is already tracked in #91536. |
This code example is minimized from a wild goose chase I ran into when implementing a solution for one of the Advent of Code puzzles.
The error messages and suggestions were not helpful in solving the issue. Some of them were actively confusing - from the programmer's perspective, the variables clearly need mutability in some form - yet the compiler kept insisting the
mut
keywords should be removed.Code
Current output
Other cases
Remove mut as instructed:
You know this should be mutable, and the error talks about references, so let's try
&mut
instead:Maybe use the
&mut
in a different place then?Rust Version
Anything else?
Here's the actual fix, hidden under a spoiler if anyone wants to try and figure it out first by themselves:
Solution
Additionally, a friend pointed out to me that using
for crab in crabs.iter_mut()
produces a helpful error message.The text was updated successfully, but these errors were encountered: