commit abcf400a2835e1db65d034128b25a276b61080a3
author Matthias Krüger <matthias.krueger@famsik.de> Thu May 23 14:09:22 2024 +0200
committer GitHub <noreply@github.com> Thu May 23 14:09:22 2024 +0200
tree 6b14a27b23931535e457dd5fd7c4b28937021ff7
parent 39d2f2affdd6b2856ab4b91359cc0d32b90bd26f
parent c24148ef7b1d4a280cca60e2001848da70ff07dc

Rollup merge of #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 https://github.com/rust-lang/rust/issues/116652

This is very similar to https://github.com/rust-lang/rust/pull/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`*