Misleading error message - Returning Option<T> when Clone not implemented

[AustinHellerRepo]

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).

Example:

struct MyStruct<T>
{
    value: Arc<RwLock<Option<T>>>,
}

impl<T> MyStruct<T>
{
    fn get_value(&self) -> Option<T> {
        let locked_value = self.value.read().unwrap();
        locked_value.as_ref().map(|value| value.clone())
    }
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9ab38c00a0a33a5c07b2aa42fa510762

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.

[compiler-errors]

You should probably provide a more complete code sample which demonstrates the bug.

[AustinHellerRepo]

You should probably provide a more complete code sample which demonstrates the bug.

Sure thing. I have updated the original example accordingly. Please let me know if this is still unclear or incomplete.

[fmease]

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]

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.