You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Misleading error message - Returning Option<T> when Clone not implemented #136151
When a function returns Option<T> and the function is basically a wrapper on an Arc<RwLock<Option<T>>> but T does not implement Clone then the code self.value.read().unwrap().as_ref().map(|value| value.clone()) will show a compile error "mismatched types" as the return type is Option<_> and found Option<&_>. This suggests that I need to clone the value, but I am already doing that. Trying to dereference the value also fails with the error that the T does not implement Copy (nor do I want it to).
I expected to see this happen:
The underlying issue of "no method named clone found for type" is the true underlying problem that is hidden from the developer.
Instead, this happened:
I was misdirected to the return type being invalid.
I was under the impression that bad or misleading error messages in Rust are considered bugs, but if that is not the case please let me know what I need to do to help resolve this issue. Thank you.
Edit:
While constructing the more complete example, I noticed that omitting the .as_ref() then caused the compiler to properly call out the lack of Clone. When I added T: Clone then an error would appear since I was missing .as_ref(). This bug demonstrates that if you already start with .as_ref() included, that the compiler fails to point you to the lack of Clone.
This looks like a more complicated variant of the closed issue #95535 (fixed by #95585).
See also closed issue #91532 (fixed by #118076) and closed issue #121524 (fixed by #122174).
Lastly, CC the open issue #91536 and the open tracking issue #83099.
Activity
compiler-errors commentedon Jan 27, 2025
You should probably provide a more complete code sample which demonstrates the bug.
AustinHellerRepo commentedon Jan 27, 2025
Sure thing. I have updated the original example accordingly. Please let me know if this is still unclear or incomplete.
fmease commentedon Jan 27, 2025
This looks like a more complicated variant of the closed issue #95535 (fixed by #95585).
See also closed issue #91532 (fixed by #118076) and closed issue #121524 (fixed by #122174).
Lastly, CC the open issue #91536 and the open tracking issue #83099.
AustinHellerRepo commentedon Jan 27, 2025
So long as there is at least one open issue for this problem, it makes sense to close this one. Thanks for reviewing this issue.
estebank commentedon Aug 12, 2025
Current output, no change: