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

[oli-obk]

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

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 #116652

This is very similar to #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*

[oli-obk]

@rfcbot merge

See main post for an explanation of the new behaviour. Imo this is the expected behaviour, especially as we already do this for other types:

fn k() -> impl Sized {
    let x = match true {
        true => {
            (k(),)
        }
        false => ((),),
    };
    todo!()
}

[rfcbot]

Team member @oli-obk has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @aliemjay
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[camsteffen]

I think this would resolve #101705?

[compiler-errors]

@camsteffen: I don't believe so. This PR only has to do with cases where we're coercing to/from opaque impl Trait types. That issue has to do with the fact that we don't coerce tuples field-by-field.

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[jackh726]

r=me if you don't want to wait for @compiler-errors

[oli-obk]

@bors r=jackh726

[bors]

📌 Commit c24148e has been approved by jackh726

It is now in the queue for this repository.