Mir: Refactor calls to permit calls that cannot panic and to better accommodate calls that always panic

[nikomatsakis]

Today, calls are always basic block terminators. This is unnecessary for calls that cannot panic. We might consider adding a call rvalue. The plus side is that it permits fewer basic blocks and in particular permits avoiding the unwinding code. The minus side is that it means more than one way for a call to happen.

Another thing is that calls today always have two successors. But for fns of type -> !, they never return normally, so they should only have a panic successor.

It might be better to leave calls as always being terminators, but just have the number of successors be either 1 or 2. If the number of successors is 1, then the fn is either diverging (-> !), in which case this is a panic successor, or else it means the fn is known not to panic somehow.

cc @Aatch you were mentioning this

[Aatch]

One advantage of leaving calls as terminators is that it makes inlining at the MIR level easier as you don't need to (potentially) split an existing basic block.

[nikomatsakis]

@Aatch interesting point. I think I am persuaded that the right thing is for them to stay as terminators but to have more flexibility about number of successors.

[RalfJung]

From a theoretical perspective, relating the MIR to a CPS version of Rust, I also agree that calls should always terminate a basic block. This implies that every basic block in MIR corresponds exactly to a lambda-expression in CPS, and (proper Rust) functions never return; they always call a return continuation. If functions in MIR could live in the middle of a basic block, that would correspond to a function returning back to its caller in the CPS, which should just never be the case.

Whether functions take a return continuation, a panic continuation, or both - that's of course completely flexible.

[nagisa]

I do not see much problem with call being a terminator either. When it comes to non-panicking or diverging functions LLVM’s call can always be followed by unconditional br to its only viable successor. While that does introduce some extra basic blocks, majority of calls will be invoked anyway.