Surprising non-idempotent behavior on {integer} inference + method resolution

[slanterns]

Excerpt from Zulip (originally https://rust-lang.zulipchat.com/#narrow/stream/144729-t-types/topic/Question.20from.20t-spec/near/422487076):

trait Trait {
    fn abs(self) -> Self;
}

impl Trait for i64 {
    fn abs(self) -> Self {
        2 * self
    }
}

fn main() {
    let x = 42;
    println!("{}", x.abs());
    println!("{}", x.abs());
}

Output (playground):

84
42

I find and repost the above code snippets from Zulip to a discussion group, and someone think it to be a counterintuitive oddity which deserves more discussion. Open the issue to see if there is anything can be improved (like adding a warning).

[darkyzhou]

I observed more wired behaviors and wondered if it is actually a feature.

1. It seems the first call is resolved to Trait::abs but the second one to core::num::<impl i64>::abs(which is a const fn). According to Method-call expressions there should be a compilation error.

https://godbolt.org/z/f4hn9K9cn

2. It seems only the first call in a block will be resolved to Trait::abs and all the calls after in the same block to the latter.

[DarkHighness]

If let x : i64 = 42; then both calls will be resolved to core::num::<impl i64>::abs

https://godbolt.org/z/Mn4TEseMj

[chikaku]

If let x : i64 = 42; then both calls will be resolved to core::num::<impl i64>::abs

https://godbolt.org/z/Mn4TEseMj

I guess the type infer cause first x.abs() call search abs method and Trait::abs is found. Once the type of x is inferred to be i64, then it will use core::num::abs.

[slanterns]

In the Zulip link from the description, errs has already given a clear explanation for the cause (see also someone on X.) The only question is whether such behavior is optimal.

[compiler-errors]

I don't believe this is possible to fix with a lot of fallout. See CI failures on #121459, we can't even bootstrap core for example.

[slanterns]

I don't expect much real-world code to include this pattern, so it may not be worthwhile to make changes to inference. Will it be a good idea to have a warn-by-default lint about such trait impl on numeric types with ambiguous names with inherent methods?

[Jules-Bertholet]

Could this be changed over an edition?

[jieyouxu]

It just occurred to me this is a duplicate of #99405 (the code example and output are identical, lol), and related to #72498.

[jieyouxu]

Closing this as a duplicate of #99405, please continue discussion in that issue.