create a lint for tracking "tainted" fallback around abrupt expressions and `!` type

[nikomatsakis]

As part of #65992, we want to create a lint that warns about cases where changing the fallback for type variables from () to ! will create problems. This issue is tracking that implementation work.

Edit 2020-10-05: stream for work on this, https://rust-lang.zulipchat.com/#narrow/stream/259160-t-lang.2Fproject-never-type

Current status and next steps

• prototype lint and verify that it works on the example test cases
• turn the lint to deny by default and make sure libstd builds
• create a helper function for adding to dead_nodes that explains what is going on, document that this function is invoked on the "way up" the tree, so that nodes are added to dead_nodes set if they diverge before completing (or they never start)
• test against the objc crate version that had problems
• run a "crater check" run and see the results
• improve the error message

[nikomatsakis]

We are discussing this on Zulip.

[Centril]

Removing C-future-compatibility as this is not ever meant to become a hard error.

[nikomatsakis]

Collecting examples.

This is the canonical example where we ran into trouble:

fn unconstrained_return<T>() -> Result<T, String> {
    let ffi: fn() -> T = transmute(some_pointer);
    Ok(ffi())
}
fn foo() {
    match unconstrained_return::<_>() {
        Ok(x) => x,  // `x` has type `_`, which is unconstrained
        Err(s) => panic!(s),  // … except for unifying with the type of `panic!()`
        // so that both `match` arms have the same type.
        // Therefore `_` resolves to `!` and we "return" an `Ok(!)` value.
    };
}

[nikomatsakis]

Another example (playground), this one uses if/else and not a local variable:

#![feature(never_type_fallback)]

fn make_unit() {
}

fn unconstrained_return<T>() ->T {
    unsafe {
        let make_unit_fn: fn() = make_unit;
        let ffi: fn() -> T = std::mem::transmute(make_unit_fn);
        ffi()
    }
}

fn main() {
    let _ = if true {
      unconstrained_return()
    } else {
      panic!()
    };
}

[nikomatsakis]

We have a branch on my repository that identifies type variables that got their value as a result of diverging fallback (and hence will change from () to ! when the feature gate switches).

We are currently issuing way too many warnings.

What we need to do is to narrow down the warnings to problematic cases.

The ideal is probably "if the type of any live expression E is some variable V where V got its value from diverging fallback, issue a warning" -- this should never happen, as it would either be compilation error, UB, or an unexpected panic.