False positive for unstable_name_collisions lint

[coolreader18]

Cargo.toml:

[package]
name = "playground"
version = "0.1.0"
edition = "2018"

[dependencies]
lexical-core = "0.7"

lib.rs:

fn link_lexical_core() {
    let _ = lexical_core::get_inf_string();
}

fn huh() {
    let _x = 1u32 >> 32.wrapping_sub(1usize) as u32;
}

on cargo c:

warning: a method with this name may be added to the standard library in the future
 --> src/lib.rs:6:25
  |
6 |     let _x = 1u32 >> 32.wrapping_sub(1usize) as u32;
  |                         ^^^^^^^^^^^^
  |
  = note: `#[warn(unstable_name_collisions)]` on by default
  = warning: once this method is added to the standard library, the ambiguity may cause an error or change in behavior!
  = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
  = help: call with fully qualified syntax `lexical_core::Integer::wrapping_sub(...)` to keep using the current method

error[E0689]: can't call method `wrapping_sub` on ambiguous numeric type `{integer}`
 --> src/lib.rs:6:25
  |
6 |     let _x = 1u32 >> 32.wrapping_sub(1usize) as u32;
  |                         ^^^^^^^^^^^^
  |
help: you must specify a concrete type for this numeric value, like `i32`
  |
6 |     let _x = 1u32 >> 32_i32.wrapping_sub(1usize) as u32;
  |                      ^^^^^^

error: aborting due to previous error; 1 warning emitted

Fixing the original error by adding a suffix to the integer literal gets rid of the unstable_name_collisions warning as well. This doesn't give the unstable_name_collisions warning:

fn link_lexical_core() {
    let _ = lexical_core::get_inf_string();
}

fn huh() {
    let _x = 1u32 >> 32usize.wrapping_sub(1usize) as u32;
}

Maybe rustc is noticing that Integer is implemented for exactly the same set of types that a bare integer literal could be? And it assumes that since that method wasn't fully resolved, that it's an unstable method, and doesn't check that it's already stable?

[eggyal]

Okay, what's happening here...

In rustc_typeck::check::method::probe::consider_candidates, there are two applicable_candidates:

• compiler_builtins::int::Int::wrapping_sub; and
• lexical_core::util::num::Integer::wrapping_sub.

The first of these is unstable:

DEBUG rustc_middle::middle::stability stability: inspecting def_id=DefId(3:285 ~ compiler_builtins[702f]::int::Int::wrapping_sub) span=src/main.rs:6:25: 6:37 (#0) of stability=Some(Stability { level: Unstable { reason: Some("this crate is being loaded from the sysroot, an unstable location; did you mean to load this crate from crates.io via `Cargo.toml` instead?"), issue: Some(27812), is_soft: false }, feature: "rustc_private" })

And so there actually is a collision against an unstable name, and the emitted warning is correct. Adding a suffix to the integer literal changes the builtin candidate from the unstable one above to that on the relevant primitive (which is stable).

Would emitting the path of the clashing unstable item, or perhaps the unstable reason above, make this diagnostic clearer?

[jonas-schievink]

None of those traits are in scope though, so I'm not sure why they would ever even be considered for method dispatch

[eggyal]

@jonas-schievink:

None of those traits are in scope though, so I'm not sure why they would ever even be considered for method dispatch

When no in-scope match can be found, all traits are searched (for diagnostics purposes)...

├─31ms DEBUG rustc_typeck::check::method::probe pick_method(self_ty={integer})
├─31ms DEBUG rustc_typeck::check::method::probe searching inherent candidates
├─31ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─31ms DEBUG rustc_typeck::check::method::probe searching extension candidates
├─31ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─31ms DEBUG rustc_typeck::check::method::probe searching unstable candidates
├─31ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─31ms DEBUG rustc_typeck::check::method::probe pick_method(self_ty=&{integer})
├─31ms DEBUG rustc_typeck::check::method::probe searching inherent candidates
├─31ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─31ms DEBUG rustc_typeck::check::method::probe searching extension candidates
├─31ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─31ms DEBUG rustc_typeck::check::method::probe searching unstable candidates
├─31ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─31ms DEBUG rustc_typeck::check::method::probe pick_method(self_ty=&mut {integer})
├─31ms DEBUG rustc_typeck::check::method::probe searching inherent candidates
├─31ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─32ms DEBUG rustc_typeck::check::method::probe searching extension candidates
├─32ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─32ms DEBUG rustc_typeck::check::method::probe searching unstable candidates
├─32ms DEBUG rustc_typeck::check::method::probe applicable_candidates: []
├─32ms DEBUG rustc_typeck::check::method::probe pick: actual search failed, assemble diagnostics
...
├─1007ms DEBUG rustc_typeck::check::method::probe assemble_extension_candidates_for_trait(trait_def_id=DefId(3:263 ~ compiler_builtins[702f]::int::Int))
... 
├─1037ms DEBUG rustc_typeck::check::method::probe assemble_extension_candidates_for_trait(trait_def_id=DefId(16:242 ~ lexical_core[1557]::util::num::Integer))