typeck has an different notion of reachability from liveness

[arielb1]

for example:

enum Void {}
// this uses middle::liveness reachability - the end of the
// function is not reachable
fn compiles() -> Void {
    loop {
        panic!();
        break
    };
}

// this uses typeck reachability - the end of the block
// is reachable, despite the code being identical.
fn does_not_compile() -> Void {
    let a: Void = { //~ ERROR mismatched types
        loop {
            panic!();
            break
        };
    };
    a
}

fn main() {}

[nagisa]

My guess would be liveness using proper dataflow-analysis, and typeck only considering loop to be diverging if it is not break-d out from.

We recently investigated typeck behaviour with @nikomatsakis (or, rather, @nmatsakis did) when trying to replicate it for loops in MIR builder.

[arielb1]

@nagisa

Right - I already checked that. That's the problem - typeck essentially considers all breaks to be always reachable, while liveness uses CFG reachability. The question is what we want to do about it - there is some plan to allow for unreachable patterns, and in that case CFG reachability would require pattern reachability, at least to be consistent.

A few alternatives:

• Outside of match, the AST-node reachability graph is pretty syntactical, so we could possibly evaluate it inside typeck.
• We could have all block-end units be type-variables with () only as a default, and check that all reachable block ends are () in a later pass. This would be an inference-breaking-change - we would need to see how much it affects real code.

[Mark-Simulacrum]

Both functions currently do not compile with the same mismatched types error. Since there's no longer a difference between the two, I'm going to assume that means this is fixed -- "typeck has an different notion of reachability from liveness" is no longer true, at least based on the code above.

Please reopen with an explanation and/or a code example which displays the difference if this is still the case.