incorrect unstable_name_collision warning for unstable inherent method name

[tspiteri]

Compiling the code below with nightly produces an unstable_name_collision warning. However the code works after enabling the feature gate, I presume because the unstable method is inherent and takes precedence over trait methods. In this particular case, it can still be worth warning that the behaviour of the standard library method can be different, but the current “warning: once this method is added to the standard library, there will be ambiguity here, which will cause a hard error!” is incorrect.

//#![feature(euclidean_division)]
trait DivEuc {
    fn div_euc(self, rhs: Self) -> Self;
}
impl DivEuc for u32 {
    fn div_euc(self, rhs: Self) -> Self { self / rhs }
}
fn main() {
    println!("{}", 12u32.div_euc(3));
}

[varkor]

cc @kennytm, as this lint comes from #48552.

[kennytm]

What about this?

warning: once this method is added to the standard library, there will be ambiguity here, which will cause a hard error or change of behavior!

It seems the message is too long though.

[varkor]

Or simply:

warning: once this method is added to the standard library, the ambiguity may cause an error or change in behaviour!

(which is even shorter than the original.)

[tspiteri]

If the trait method parameters are different from the inherent method parameters, it could end up leading to a hard error for a different reason. For example for the code below, opening the feature gate will cause a hard error, but because of a type mismatch rather than because of ambiguity.

//#![feature(euclidean_division)]
trait DivEuc {
    fn div_euc(self, rhs: u8) -> Self;
}
impl DivEuc for u32 {
    fn div_euc(self, rhs: u8) -> Self { self / rhs as u32 }
}
fn main() {
    println!("{}", 12u32.div_euc(3u8));
}

So a more generic error like @varkor suggests is better.