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

go through uses of DefineOpaqueTypes::No and either document or change them #116652

Open
oli-obk opened this issue Oct 12, 2023 · 3 comments
Open
Assignees
Labels
A-impl-trait Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Oct 12, 2023

This issue can be resolved in individual steps (each application of all steps should be their own commit!):

  1. flip a single usage of DefineOpauqeTypes::No to Yes
  2. see what tests fail, document the site by mentioning the test in a comment, revert to ::No, and open a PR.
  3. If no tests fail, still open a PR and assign to @oli-obk or @compiler-errors and leave a comment that there's no test exercising it. We'll try to come up with a test and/or run crater to find examples.
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Oct 12, 2023
@oli-obk oli-obk added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. A-impl-trait Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Oct 12, 2023
@goldpanth3r
Copy link

Hey @oli-obk! I would like to try to contribute to this. Could you explain Step 1:flip a site to Yes? I tried to search for site and DefineOpaqueTypes::No in the codebase, but couldn't learn much.

@matthiaskrgr
Copy link
Member

I think it means to just search for DefineOpaqueTypes::No for example:

compiler/rustc_trait_selection/src/traits/fulfill.rs:540:                                    .eq(DefineOpaqueTypes::No, a.args, b.args)

and change it to DefineOpaqueTypes::Yes 🙃

@chansuke
Copy link
Contributor

@rustbot claim

@oli-obk oli-obk assigned oli-obk and unassigned chansuke Feb 21, 2024
@oli-obk oli-obk removed the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. 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 Apr 24, 2024
More DefineOpaqueTypes::Yes

This accepts more code on stable. It is now possible to have match arms return a function item `foo::<ConcreteType>` and a function item `foo::<OpaqueTypeInDefiningScope>` in another, and that will constrain `OpaqueTypeInDefiningScope` to have the hidden type `ConcreteType`. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
// The function item whose generic params we want to merge.
fn foo<T>(t: T) -> T { t }
// Helper ensuring we can constrain `T` on `F` without explicitly specifying it
fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F { f }

fn k() -> impl Sized {
    let x = match true {
        true => {
            // `f` is `FnDef(foo, [infer_var])`
            let f = foo;
            // Get a value of an opaque type on stable
            let t = k();
            // this returns `FnDef(foo, [k::return])`
            bind(t, f)
        }
        false => foo::<()>,
    };
    todo!()
}
```

r? `@compiler-errors`

cc rust-lang#116652
fmease added a commit to fmease/rust that referenced this issue Apr 24, 2024
More DefineOpaqueTypes::Yes

This accepts more code on stable. It is now possible to have match arms return a function item `foo::<ConcreteType>` and a function item `foo::<OpaqueTypeInDefiningScope>` in another, and that will constrain `OpaqueTypeInDefiningScope` to have the hidden type `ConcreteType`. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
// The function item whose generic params we want to merge.
fn foo<T>(t: T) -> T { t }
// Helper ensuring we can constrain `T` on `F` without explicitly specifying it
fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F { f }

fn k() -> impl Sized {
    let x = match true {
        true => {
            // `f` is `FnDef(foo, [infer_var])`
            let f = foo;
            // Get a value of an opaque type on stable
            let t = k();
            // this returns `FnDef(foo, [k::return])`
            bind(t, f)
        }
        false => foo::<()>,
    };
    todo!()
}
```

r? ``@compiler-errors``

cc rust-lang#116652
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Apr 24, 2024
Rollup merge of rust-lang#123794 - oli-obk:define_opaque_types2, r=lcnr

More DefineOpaqueTypes::Yes

This accepts more code on stable. It is now possible to have match arms return a function item `foo::<ConcreteType>` and a function item `foo::<OpaqueTypeInDefiningScope>` in another, and that will constrain `OpaqueTypeInDefiningScope` to have the hidden type `ConcreteType`. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
// The function item whose generic params we want to merge.
fn foo<T>(t: T) -> T { t }
// Helper ensuring we can constrain `T` on `F` without explicitly specifying it
fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F { f }

fn k() -> impl Sized {
    let x = match true {
        true => {
            // `f` is `FnDef(foo, [infer_var])`
            let f = foo;
            // Get a value of an opaque type on stable
            let t = k();
            // this returns `FnDef(foo, [k::return])`
            bind(t, f)
        }
        false => foo::<()>,
    };
    todo!()
}
```

r? ``@compiler-errors``

cc rust-lang#116652
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Apr 25, 2024
More DefineOpaqueTypes::Yes

This accepts more code on stable. It is now possible to have match arms return a function item `foo::<ConcreteType>` and a function item `foo::<OpaqueTypeInDefiningScope>` in another, and that will constrain `OpaqueTypeInDefiningScope` to have the hidden type `ConcreteType`. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
// The function item whose generic params we want to merge.
fn foo<T>(t: T) -> T { t }
// Helper ensuring we can constrain `T` on `F` without explicitly specifying it
fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F { f }

fn k() -> impl Sized {
    let x = match true {
        true => {
            // `f` is `FnDef(foo, [infer_var])`
            let f = foo;
            // Get a value of an opaque type on stable
            let t = k();
            // this returns `FnDef(foo, [k::return])`
            bind(t, f)
        }
        false => foo::<()>,
    };
    todo!()
}
```

r? ``@compiler-errors``

cc rust-lang/rust#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue May 23, 2024
…ackh726

Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type

r? `@compiler-errors`

This accepts more code on stable. It is now possible to have match arms return a function item `foo` and a different function item `bar` in another, and that will constrain OpaqueTypeInDefiningScope to have the hidden type ConcreteType and make the type of the match arms a function pointer that matches the signature. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
fn foo<T>(t: T) -> T {
    t
}

fn bar<T>(t: T) -> T {
    t
}

fn k() -> impl Sized {
    fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F {
        f
    }
    let x = match true {
        true => {
            let f = foo;
            bind(k(), f)
        }
        false => bar::<()>,
    };
    todo!()
}
```

cc rust-lang#116652

This is very similar to rust-lang#123794, and with the same rationale:

> this is for consistency with `-Znext-solver`. the new solver does not have the concept of "non-defining use of opaque" right now and we would like to ideally keep it that way. Moving to `DefineOpaqueTypes::Yes` in more cases removes subtlety from the type system. Right now we have to be careful when relating `Opaque` with another type as the behavior changes depending on whether we later use the `Opaque` or its hidden type directly (even though they are equal), if that later use is with `DefineOpaqueTypes::No`*
rust-timer added a commit to rust-lang-ci/rust that referenced this issue May 23, 2024
Rollup merge of rust-lang#124297 - oli-obk:define_opaque_types13, r=jackh726

Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type

r? `@compiler-errors`

This accepts more code on stable. It is now possible to have match arms return a function item `foo` and a different function item `bar` in another, and that will constrain OpaqueTypeInDefiningScope to have the hidden type ConcreteType and make the type of the match arms a function pointer that matches the signature. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
fn foo<T>(t: T) -> T {
    t
}

fn bar<T>(t: T) -> T {
    t
}

fn k() -> impl Sized {
    fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F {
        f
    }
    let x = match true {
        true => {
            let f = foo;
            bind(k(), f)
        }
        false => bar::<()>,
    };
    todo!()
}
```

cc rust-lang#116652

This is very similar to rust-lang#123794, and with the same rationale:

> this is for consistency with `-Znext-solver`. the new solver does not have the concept of "non-defining use of opaque" right now and we would like to ideally keep it that way. Moving to `DefineOpaqueTypes::Yes` in more cases removes subtlety from the type system. Right now we have to be careful when relating `Opaque` with another type as the behavior changes depending on whether we later use the `Opaque` or its hidden type directly (even though they are equal), if that later use is with `DefineOpaqueTypes::No`*
github-actions bot pushed a commit to rust-lang/miri that referenced this issue May 24, 2024
Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type

r? `@compiler-errors`

This accepts more code on stable. It is now possible to have match arms return a function item `foo` and a different function item `bar` in another, and that will constrain OpaqueTypeInDefiningScope to have the hidden type ConcreteType and make the type of the match arms a function pointer that matches the signature. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
fn foo<T>(t: T) -> T {
    t
}

fn bar<T>(t: T) -> T {
    t
}

fn k() -> impl Sized {
    fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F {
        f
    }
    let x = match true {
        true => {
            let f = foo;
            bind(k(), f)
        }
        false => bar::<()>,
    };
    todo!()
}
```

cc rust-lang/rust#116652

This is very similar to rust-lang/rust#123794, and with the same rationale:

> this is for consistency with `-Znext-solver`. the new solver does not have the concept of "non-defining use of opaque" right now and we would like to ideally keep it that way. Moving to `DefineOpaqueTypes::Yes` in more cases removes subtlety from the type system. Right now we have to be careful when relating `Opaque` with another type as the behavior changes depending on whether we later use the `Opaque` or its hidden type directly (even though they are equal), if that later use is with `DefineOpaqueTypes::No`*
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue May 24, 2024
Allow coercing functions whose signature differs in opaque types in their defining scope into a shared function pointer type

r? `@compiler-errors`

This accepts more code on stable. It is now possible to have match arms return a function item `foo` and a different function item `bar` in another, and that will constrain OpaqueTypeInDefiningScope to have the hidden type ConcreteType and make the type of the match arms a function pointer that matches the signature. So the following function will now compile, but on master it errors with a type mismatch on the second match arm

```rust
fn foo<T>(t: T) -> T {
    t
}

fn bar<T>(t: T) -> T {
    t
}

fn k() -> impl Sized {
    fn bind<T, F: FnOnce(T) -> T>(_: T, f: F) -> F {
        f
    }
    let x = match true {
        true => {
            let f = foo;
            bind(k(), f)
        }
        false => bar::<()>,
    };
    todo!()
}
```

cc rust-lang/rust#116652

This is very similar to rust-lang/rust#123794, and with the same rationale:

> this is for consistency with `-Znext-solver`. the new solver does not have the concept of "non-defining use of opaque" right now and we would like to ideally keep it that way. Moving to `DefineOpaqueTypes::Yes` in more cases removes subtlety from the type system. Right now we have to be careful when relating `Opaque` with another type as the behavior changes depending on whether we later use the `Opaque` or its hidden type directly (even though they are equal), if that later use is with `DefineOpaqueTypes::No`*
workingjubilee added a commit to workingjubilee/rustc that referenced this issue May 25, 2024
…ompiler-errors

Some unstable changes to where opaque types get defined

None of these can be reached from stable afaict.

r? `@compiler-errors`

cc rust-lang#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue May 25, 2024
…ompiler-errors

Some unstable changes to where opaque types get defined

None of these can be reached from stable afaict.

r? ``@compiler-errors``

cc rust-lang#116652
rust-timer added a commit to rust-lang-ci/rust that referenced this issue May 26, 2024
Rollup merge of rust-lang#124080 - oli-obk:define_opaque_types10, r=compiler-errors

Some unstable changes to where opaque types get defined

None of these can be reached from stable afaict.

r? ``@compiler-errors``

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
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
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
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Jun 19, 2024
…h726

Change a `DefineOpaqueTypes::No` to `Yes` in diagnostics code

Explanation in comments of the function.

r? ``@compiler-errors``

cc rust-lang#116652
fee1-dead added a commit to fee1-dead-contrib/rust that referenced this issue Jun 19, 2024
…h726

Change a `DefineOpaqueTypes::No` to `Yes` in diagnostics code

Explanation in comments of the function.

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

cc rust-lang#116652
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jun 19, 2024
Rollup merge of rust-lang#126675 - oli-obk:diagnostics_opaque, r=jackh726

Change a `DefineOpaqueTypes::No` to `Yes` in diagnostics code

Explanation in comments of the function.

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

cc rust-lang#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 24, 2024
…, r=compiler-errors

Ensure we don't accidentally succeed when we want to report an error

This also changes the `DefiningOpaqueTypes::No` to `Yes` without adding tests, as it is solely run on the error path to improve diagnostics. I was unable to provide a test that changes diagnostics, as all the tests I came up with ended up successfully constraining the opaque type and thus succeeding the coercion.

r? `@compiler-errors`

cc rust-lang#116652
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 24, 2024
…, r=compiler-errors

Ensure we don't accidentally succeed when we want to report an error

This also changes the `DefiningOpaqueTypes::No` to `Yes` without adding tests, as it is solely run on the error path to improve diagnostics. I was unable to provide a test that changes diagnostics, as all the tests I came up with ended up successfully constraining the opaque type and thus succeeding the coercion.

r? ``@compiler-errors``

cc rust-lang#116652
compiler-errors added a commit to compiler-errors/rust that referenced this issue Jun 24, 2024
…, r=compiler-errors

Ensure we don't accidentally succeed when we want to report an error

This also changes the `DefiningOpaqueTypes::No` to `Yes` without adding tests, as it is solely run on the error path to improve diagnostics. I was unable to provide a test that changes diagnostics, as all the tests I came up with ended up successfully constraining the opaque type and thus succeeding the coercion.

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

cc rust-lang#116652
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jun 24, 2024
Rollup merge of rust-lang#126673 - oli-obk:dont_rely_on_err_reporting, r=compiler-errors

Ensure we don't accidentally succeed when we want to report an error

This also changes the `DefiningOpaqueTypes::No` to `Yes` without adding tests, as it is solely run on the error path to improve diagnostics. I was unable to provide a test that changes diagnostics, as all the tests I came up with ended up successfully constraining the opaque type and thus succeeding the coercion.

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

cc rust-lang#116652
bors added a commit to rust-lang-ci/rust that referenced this issue Jun 25, 2024
…piler-errors

Allow constraining opaque types during various unsizing casts

allows unsizing of tuples, arrays and Adts to constraint opaque types in their generic parameters to concrete types on either side of the unsizing cast.

Also allows constraining opaque types during trait object casts that only differ in auto traits or lifetimes.

cc rust-lang#116652
flip1995 pushed a commit to flip1995/rust-clippy that referenced this issue Jun 28, 2024
…rrors

Some unstable changes to where opaque types get defined

None of these can be reached from stable afaict.

r? ``@compiler-errors``

cc rust-lang/rust#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.
Projects
Development

No branches or pull requests

5 participants