Skip to content

inherent method selection uses subtyping even when using paths #126227

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
lcnr opened this issue Jun 10, 2024 · 0 comments · Fixed by #129073
Closed

inherent method selection uses subtyping even when using paths #126227

lcnr opened this issue Jun 10, 2024 · 0 comments · Fixed by #129073
Labels
T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@lcnr
Copy link
Contributor

lcnr commented Jun 10, 2024

struct B<T>(T);

impl B<fn(&'static ())> {
    fn method(self) {
        println!("hey");
    }
}

fn foo(x: B<for<'a> fn(&'a ())>) {
    x.method(); // ok, method call
    B::<for<'a> fn(&'a ())>::method(x); // ok, explicit path
}

fn main() {
   
}

I would like us to change method selection for associated items to use equality. It feels very wrong to completely ignore the user type annotation here:

struct B<T>(T);

impl B<fn(&'static ())> {
    fn method(self) {
        println!("hey");
    }
}

fn foo(y: B<fn(&'static ())>) {
    // looks like it requires a hr fn pointer,
    // but we never check that.
    B::<for<'a> fn(&'a ())>::method(y);
}

fn main() {}

cc #126128 @compiler-errors @oli-obk

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jun 10, 2024
@lcnr lcnr added A-resolve Area: Name/path resolution done by `rustc_resolve` specifically T-types Relevant to the types team, which will review and decide on the PR/issue. and removed A-resolve Area: Name/path resolution done by `rustc_resolve` specifically labels Jun 10, 2024
@saethlin saethlin removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jul 4, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 14, 2024
…=<try>

Relate receiver invariantly in method probe for `Mode::Path`

Reverts rust-lang#126128
Fixes the part of rust-lang#122317 which always used subtyping instead of eq
Fixes rust-lang#126227 (TODO: test)

WIP: description

r? lcnr
fee1-dead added a commit to fee1-dead-contrib/rust that referenced this issue Sep 17, 2024
… r=lcnr

Relate receiver invariantly in method probe for `Mode::Path`

Effectively reverts part of rust-lang#126128
Fixes rust-lang#126227

This PR changes method probing to use equality for fully path-based method lookup, and subtyping for receiver `.` method lookup.

r? lcnr
@bors bors closed this as completed in e9e13a6 Sep 17, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants