Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

inherent method selection uses subtyping even when using paths #126227

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: Path resolution T-types Relevant to the types team, which will review and decide on the PR/issue. and removed A-resolve Area: Path resolution 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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