Fix: Complete methods on all unsuffixed numeric literals

[HuaGu-Dragon]

Close: #21312

Release Note:

• Fix: Complete methods on all numeric types for unsuffixed numeric literals

This PR fixes method completion for unsuffixed numeric literals (like 23. and 2.0.) to show methods from all applicable numeric types, not just the default inferred type.

Problem

Previously:

• 23. only showed methods from i32 (not i64, u64, etc.)
• 2.0. only showed methods from f64 (not f32, f16, etc.)

This made #21312 occured.

Solution

Now checks methods on ALL applicable types:

• Integer literals (23.): Checks all integer types (i8, i16, i32, i64, i128, isize, u8, u16, u32, u64, u128, usize)
• Float literals (2.0.): Checks all float types (f16, f32, f64, f128)
• Proper deduplication: Uses FxHashSet<Function> to ensure each method appears only once

Changes

1. crates/hir/src/lib.rs : Added constructor methods for all numeric builtin types
2. crates/ide-completion/src/completions/dot.rs : Enhanced completion logic with deduplication
3. crates/ide-completion/src/tests/expression.rs : Added comprehensive tests

Example

Before:

trait MyTrait { fn my_method(&self) {} }
impl MyTrait for i64 {}

fn main() {
    23.my_method();  // ❌ No completion
}

After:

trait MyTrait { fn my_method(&self) {} }
impl MyTrait for i64 {}

fn main() {
    23.my_method();  // ✅ my_method() now available!
}

Usage of AI tools

I implemented the logic and wrote the code.
I used AI only to brainstorm ideas , propose variable/struct names, and draft inline comments.
I manually reviewed and edited every AI suggestion before committing. No code was blindly accepted from the tool.

[Copilot]

Pull request overview

This PR fixes method completion for unsuffixed numeric literals to show methods from all applicable numeric types rather than just the default inferred type.

• Adds constructor methods for all numeric builtin types (i8-i128, u8-u128, f16-f128) in HIR
• Enhances dot completion logic to check methods across all integer types for integer literals (e.g., 23.) and all float types for float literals (e.g., 2.0.)
• Implements deduplication using FxHashSet to prevent duplicate method suggestions

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
crates/hir/src/lib.rs	Adds constructor methods for all numeric builtin types (i8, i16, i64, i128, isize, u8, u16, u32, u64, u128, usize, f16, f32, f64, f128)
crates/ide-completion/src/completions/dot.rs	Implements multi-type method completion for unsuffixed numeric literals with deduplication logic
crates/ide-completion/src/tests/expression.rs	Adds test cases for integer and float literal method completion

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ChayimFriedman2]

Please note that we require disclosure when using AI tools to author a PR.

[HuaGu-Dragon]

Please note that we require disclosure when using AI tools to author a PR.

Thanks for the reminder — sorry, I missed the disclosure requirement. I’ll add the required AI‑tools disclosure, fix the issue it just mentioned , and reopen the PR shortly.

[HuaGu-Dragon]

@ChayimFriedman2 Thanks for the reminder and sorry for missing the disclosure earlier.

What I changed

• Added an explicit AI-tools disclosure to the PR description
• Fixed the issue AI mentioned and ran the tests locally.

I have reopened the PR — please let me know if anything else is needed.

[ChayimFriedman2]

Definitely don't enumerate methods for all types. That'll lead to a lot of effectively duplicated methods. Choose one type - probably f64. Look at how this is implemented for unsuffixed integers.

[HuaGu-Dragon]

Definitely don't enumerate methods for all types. That'll lead to a lot of effectively duplicated methods. Choose one type - probably f64. Look at how this is implemented for unsuffixed integers.

Got it, Thanks for the feedback! I'm enumerating all numeric types to discover traits implemented only on non-default types (e.g., a trait only on f32, not f64) - these would actually compile due to type inference but would be missed if we only check f64.

To avoid duplicate inherent methods (multiple abs() entries), I'm using:

• Inherent methods: Only from f64
• Trait methods: All float types with FxHashSet

[HuaGu-Dragon]

Hey! @ChayimFriedman2, I just looked back at this PR and have two questions.

1) About your comment

Look at how this is implemented for unsuffixed integers.

I may have misunderstood your previous comment. Are you saying there isn't an issue with unsuffixed integers? I couldn't find any relevant existing implementation, and I believe integers have the same issue.

Could you point me to the specific code you're referring to?

2) Some limitations

It works when there's a single implementation:

trait OnlyI64 { fn method(&self); }
impl OnlyI64 for i64 {} 

fn foo() {
    23.method()  // ✅ Compiles (infers i64)
}

But with multiple implementations, Rust falls back to the default type (i32/f64):

For example, this only compiles if Multi is implemented for i32, otherwise it needs a type annotation:

trait Multi { fn method(&self); }
impl Multi for u64 {}
impl Multi for i64 {}

fn foo() {
    23.method()
}

Currently, my implementation doesn't detect whether it's a single-impl or multi-impl situation. It just shows all trait methods from all integer(or float) types.

The question: Is it worth adding extra complexity to detect and avoid this ambiguous case?

Given that:

• Rust's compiler will clearly point out when a type annotation is needed
• The user can easily add a suffix (e.g., 23i64)

[ChayimFriedman2]

Are you saying there isn't an issue with unsuffixed integers?

Yes. I meant #20110, which isn't exactly the same but is similar in spirit.

Is it worth adding extra complexity to detect and avoid this ambiguous case?

Nope. Just list all methods for f64 and that's it.

[HuaGu-Dragon]

Nope. Just list all methods for f64 and that's it.

Got it! But I want to clarify my understanding:

Current behavior (before my PR):

• 2.0. → Already detects it as f64 and lists f64's methods
• Issue Cannot complete f32 methods on unsuffixed float #21312 happens because it doesn't check trait methods on other float types (f32, f16, etc.)

Same issue exists for integers:

• 23. → Detects as i32 and shows i32's inherent methods
• But doesn't check trait methods on other integer types (i64, u64, etc.)

Example of the problem:

trait OnlyF32 { fn method(&self); }
impl OnlyF32 for f32 {}

trait OnlyU32 { fn method(&self); }
impl OnlyU32 for u32 {}

fn foo() {
    2.0.method()  // ✅ Compiles (type inference picks f32)
                  // ❌ But no completion shown
              
    2.method()  // ✅ Compiles (type inference picks u32)
                  // ❌ But no completion shown
}

Should I close this PR, since before my PR it already listed all methods for f64 ?

[ChayimFriedman2]

Oh, I must admit that I misread the issue, and now I believe that we don't want to fix this issue. Sorry for dragging you into implementing useless work!

@rust-lang/rust-analyzer just confirm you're okay with closing this and the issue as "won't fix"?

[HuaGu-Dragon]

No problem, and thanks for the review!