Hmm, something's bugging me about this. I think that the "infinite loop" behavior you were talking about is more surprising than I thought at first. Consider this example, where we use a (incorrect, but perhaps unsafe) API to spawn threads, relying on a dtor to join them:
let scope = Scope::new();
let mut foo = 22;
// dtor joins the thread
let _guard = scope.spawn(&mut foo);
loop {
foo += 1;
}
// drop of `_guard` joins the thread
This code would presumably pass borrowck, since the drop is not reachable, but that seems sort of wrong. Now, of course, this API is not safe: the safe version would use a closure, and then having "special treatment" of free regions like 'a (where it is treated as live throughout the closure body) would make things work, but that feels suboptimal. It'd be nice if we could inline the closure body and preserve the same level of type soundness. =)
I had considered in the past that MIR construction could insert false "break" edges onto infinite loops. This is a common enough technique in compilers, since some algorithms are better behaved if there is a universal path to the exit. This would not completely eliminate dead code -- example, code that is dominated by a return or break would still be dead -- but it would ensure that the EXIT block is always reachable from the START block, right? Might be something to consider.