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

DefineOpaqueTypes::No in UFC Self resolution #121404

Closed
oli-obk opened this issue Feb 21, 2024 · 2 comments · Fixed by #123962
Closed

DefineOpaqueTypes::No in UFC Self resolution #121404

oli-obk opened this issue Feb 21, 2024 · 2 comments · Fixed by #123962
Labels
A-impl-trait Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch. C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Feb 21, 2024

in

DefineOpaqueTypes::No,
we disable hidden type registration. I have been unable to craft a test case for this, as either the self_ty arg of instantiate_value_path is None, or there are no generic parameters on the self type, so it gets inference variables which end up working out fine.

As an example:

#![feature(type_alias_impl_trait)]
struct Foo<T>(T);

impl Foo<u32> {
    fn method() {}
    fn method2(self) {}
}

type Bar = impl Sized;

fn bar() -> Bar {
    42_u32
}

impl Foo<Bar> {
    fn foo() -> Bar {
        Self::method();
        //~^ ERROR: no function or associated item named `method` found for struct `Foo<Bar>`
        Foo::<Bar>::method();
        //~^ ERROR: no function or associated item named `method` found for struct `Foo<Bar>`
        let x = Foo(bar());
        Foo::method2(x);
        let x = Self(bar());
        Self::method2(x);
        //~^ ERROR: no function or associated item named `method2` found for struct `Foo<Bar>`
        todo!()
    }
}

fn main() {}

the Foo::method2(x); works fine, none of the others do, and none of them have a self_ty set here either.

Wrapping the types in <> does not have an effect, even if the code seems to hint at that:

// `<T>::assoc` will end up here, and so

any ideas @compiler-errors

cc #121394

@oli-obk oli-obk added C-cleanup Category: PRs that clean code up or issues documenting cleanup. A-impl-trait Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch. labels Feb 21, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 21, 2024
@compiler-errors
Copy link
Member

@oli-obk: This DefineOpaqueTypes::Yes is unreachable until we fix the method (well, associated item) probing in resolve_ty_and_res_fully_qualified_call.

@oli-obk
Copy link
Contributor Author

oli-obk commented Feb 21, 2024

yay, thought so, I'll add the test with a comment that it is a bug

@Noratrieb Noratrieb removed the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 21, 2024
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 15, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

But it is also a breaking change, since `&self` and `&mut self` method calls on recursive RPIT function calls now constrain the hidden type to `&_` and `&mut _` respectively. This is not what users really expect or want from this, but there's way around this.

r? `@compiler-errors`

fixes  rust-lang#121404

cc rust-lang#116652
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 16, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

But it is also a breaking change, since `&self` and `&mut self` method calls on recursive RPIT function calls now constrain the hidden type to `&_` and `&mut _` respectively. This is not what users really expect or want from this, but there's way around this.

r? `@compiler-errors`

fixes  rust-lang#121404

cc rust-lang#116652
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 22, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

But it is also a breaking change, since `&self` and `&mut self` method calls on recursive RPIT function calls now constrain the hidden type to `&_` and `&mut _` respectively. This is not what users really expect or want from this, but there's way around this.

r? `@compiler-errors`

fixes  rust-lang#121404

cc rust-lang#116652
fmease added a commit to fmease/rust that referenced this issue Jun 13, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

r? `@compiler-errors`

fixes  rust-lang#121404

cc rust-lang#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 13, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

r? ``@compiler-errors``

fixes  rust-lang#121404

cc rust-lang#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 13, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

r? ```@compiler-errors```

fixes  rust-lang#121404

cc rust-lang#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 13, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

r? ````@compiler-errors````

fixes  rust-lang#121404

cc rust-lang#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 13, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

r? `````@compiler-errors`````

fixes  rust-lang#121404

cc rust-lang#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 14, 2024
change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

r? ``````@compiler-errors``````

fixes  rust-lang#121404

cc rust-lang#116652
@bors bors closed this as completed in 0468462 Jun 14, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jun 14, 2024
Rollup merge of rust-lang#123962 - oli-obk:define_opaque_types5, r=lcnr

change method resolution to constrain hidden types instead of rejecting method candidates

Some of these are in probes and may affect inference. This is therefore a breaking change.

This allows new code to compile on stable:

```rust
trait Trait {}

impl Trait for u32 {}

struct Bar<T>(T);

impl Bar<u32> {
    fn foo(self) {}
}

fn foo(x: bool) -> Bar<impl Sized> {
    if x {
        let x = foo(false);
        x.foo();
        //^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
    }
    todo!()
}
```

r? ```````@compiler-errors```````

fixes  rust-lang#121404

cc rust-lang#116652
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-impl-trait Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch. C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
4 participants