Notice I added explanation for LubCoerce with expected type in the end. That's because it's really how rustc currently works. You can check that by test these:

This compiles:

let esc: &[u8] = match true {
    true => b"ab", // &[u8; 2]
    false => b"c",  // &[u8; 1]
};

This failes to compile:

let esc = match true {
    true => b"ab",
    false => b"c",
};

Why?

1. Lub(&[u8], &[u8; 2]) == &[u8]
2. Lub(&[u8], &[u8; 1]) == &[u8]
3. Lub(&[u8; 2], &[u8; 1]) fails

I've sent my review as a new PR @ ldm0#1

Waiting on a lang team member to approve. :D

To check the correctness of the pseudo code, reviewers can check CoerceMany::coerce_inner() and FnCtxt::try_find_coercion_lub(). To check how compiler processes the expected type, reviewers can check FnCtxt::check_match().

So I guess an alternative would be to describe the LUB coercion more informally and less precisely. Something like the following (@ldm0 you would obviously want to amend this to include the coercion from FnDef/closures to fn pointers that started all of this). I'm curious @ehuss or others what you think of these two options.

I think I mildly prefer an informal description like this one, because I think that it is probably sufficient to give readers an intuition for what the compiler is trying to do, and I suspect that the more precise description is ultimately not sufficiently precise to be "authoratative" and hence we're better off leaving that job to the code itself.

In some contexts, the compiler must coerce together multiple types to try and find the most general type. This is called a "Least Upper Bound" coercion. Some examples where the LUB coercion algorithm is used are:

• to find the common type for a series of match arms; or
• to find the common type for the return type of a closure with multiple return statements.

In each such case, there are a set of types T0..Tn to be mutually coerced to some target type T_t, which is unknown to start. Computing the LUB coercion is done iteratively. The target type T_t begins as the type T0. For each new type Ti, we consider whether

• If Ti can be coerced to the current target type T_t, then no change is made.
• Otherwise, we check whether T_t can be coerced to Ti; if so, the T_t is changed to Ti. (This check is also conditioned on whether all of the source expressions considered thus far have implicit coercions.)
• If not, we try to compute a mutual supertype of T_t and Ti, which will become the new target type.

Examples

XXX give some interesting examples

Caveat

This description is obviously informal. Making it more precise is expected to proceed as part of a general effort to specify the Rust type checker more precisely.

The list of where LUB coercions happen should at least be an exhaustive list, not just "examples where it is performed".

Where are we with this?

Sorry for the long delay. Rewrite done. Exhaustive list added

Thanks!