Method selection chooses wrong method when one candidate has auto trait bounds

[benediktsatalia]

rust-analyzer version: rust-analyzer version: 0.3.2299-standalone

rustc version: rustc 1.84.1 (e71f9a9a9 2025-01-27)

editor or extension: VSCode with extension version v0.3.2299

code snippet to reproduce:

use std::sync::Arc;

trait Trait {
    unsafe fn overload(&self) -> u32 {
        println!("Trait overload");
        0
    }
}

impl<T: Send> Trait for T {}

struct X<T>(T);

impl<T> X<T> {
    fn overload(&self) -> u64 {
        println!("struct overload");
        0
    }
}

fn call_overload<T>(a: Arc<X<T>>) -> u64 {
    a.overload()
}

This code compiles fine, but rust-analyzer reports an error on the second-last line (a.overload()), this is the error:

call to unsafe function is unsafe and requires an unsafe function or block

So rust-analzyer seems to think that we are calling Trait::overload although in reality we are calling X::overload. What is weird is that if I remove the unsafe there is no complain even though the Trait::overload method has the wrong return type.

Also note that if I replace the Send bound by another non-auto-trait like Default and impl<T: Default> Default for X<T> { ... } then rust-analyzer does not complain, so it seems to be related to auto traits.

[ChayimFriedman2]

What is weird is that if I remove the unsafe there is no complain even though the Trait::overload method has the wrong return type.

rust-analyzer doesn't report type mismatches (yet) unless you enable experimental diagnostics.

[ChayimFriedman2]

Okay yes, this is related to auto traits. rust-analyzer doesn't handle auto traits correctly currently (because this leads to a major perf degradation, see #19122) - therefore it treats the trait impl as applying to Arc<X<T>> (which it is not, because we don't know that T: Send), so it get a priority over the inherent impl, because the inherent impl requires a deref.