fix: not complete same name inherent deref methods#22376
Conversation
Example
---
```rust
fn test(a: A) {
a.$0
}
impl core::ops::Deref for A {
type Target = B;
fn deref(&self) -> &Self::Target { loop {} }
}
trait Foo { fn foo(&self) -> u32 {} }
impl Foo for A {}
impl Foo for B {}
impl A { fn foo(&self) -> u8 {} }
impl B { fn foo(&self) -> u16 {} }
struct A {}
struct B {}
```
**Before this PR**
```text
me foo() fn(&self) -> u8
me foo() fn(&self) -> u16
me foo() (as Foo) fn(&self) -> u32
```
**After this PR**
```text
me foo() fn(&self) -> u8
me foo() (as Foo) fn(&self) -> u32
```
| } | ||
| } | ||
| }; | ||
| same_name.insert_entry(func); |
There was a problem hiding this comment.
Should move that inside the if, otherwise invisible methods can override visible methods.
There was a problem hiding this comment.
Thank you for catch this, but fixing it is not that simple, I am currently working on it
There was a problem hiding this comment.
Why inserting it under the if can't solve this?
There was a problem hiding this comment.
Because on_inherent_method is not called ordered
I think we need to block until we fix the order based on another PR
For the following code, I printed the log and output FEACDB:
pub struct A {}
pub struct B {}
pub struct C {}
pub struct D {}
pub struct E {}
pub struct F {}
impl core::ops::Deref for A {
type Target = B;
fn deref(&self) -> &Self::Target { loop {} }
}
impl core::ops::Deref for B {
type Target = C;
fn deref(&self) -> &Self::Target { loop {} }
}
impl core::ops::Deref for C {
type Target = D;
fn deref(&self) -> &Self::Target { loop {} }
}
impl core::ops::Deref for D {
type Target = E;
fn deref(&self) -> &Self::Target { loop {} }
}
impl core::ops::Deref for E {
type Target = F;
fn deref(&self) -> &Self::Target { loop {} }
}There was a problem hiding this comment.
Changing the FxHashMap to FxIndexMap here:
Should fix this.
This test is exists, for non pub methods in other crates |
Co-authored-by: Chayim Refael Friedman <chayimfr@gmail.com>
b430eba to
be99012
Compare
Fixes #20773
Motivation: #20773 (comment)
I'm not sure if
ObjectandWhereClausewere handled correctlyExample
Before this PR
After this PR