[MIR] Refine representation and translation of calls

[nagisa]

r? @nikomatsakis

This is a pretty big PR conflating changes to a few different block terminators (Call, DivergingCall, Panic, Resume, Diverge), because they are somewhat closely related.

Each commit has a pretty good description on what is being changed in each commit. The end result is greatly simplified CFG and translation for calls (no success branch if the function is diverging, no cleanup branch if there’s nothing to cleanup etc).

Fixes #30480
Fixes #29767
Partialy solves #29575
Fixes #29573

[nagisa]

Note to self: maybe self should contain a fcx too?

[nagisa]

This looks, uh, ugly? Incorrect?

[nagisa]

All in all, I think it is in a good enough spot now to begin reviewing it @nikomatsakis.

[luqmana]

AFAIK should just do the same as below: store_ty the result from Invoke to the destination.

[nagisa]

The problem here (is much harder than it looks at the first look!) is that invoke is a basic block terminator and thus we cannot add anything else to the current block. We would have to add, or rather, prepend a store instruction to a success branch, but… that’s tricky, because:

1. That’s hacky (duh);
2. I can’t seem to see anyway to do it;
3. It would make some already-generated blocks invalid (e.g. we would have to assert that success branch has higher basic-block number and has not been translated yet).

Basically, to me it seems like we should change the MIR some more and figure out if destination must be copied (or rather, avoid copying destination altogether as well as encoding the copy, if necessary) during the MIR build phase.

---

EDIT: we could also generate a temporary block with a store and branch to success block in it (still doesn’t avoid 3rd issue). Sounds like a most correct hack to do, but I’ll see if anybody has better ideas.

[nikomatsakis]

As I mentioned on IRC, I'm not sure if I think that splitting out "diverging call" into its own terminator is a good idea. My concerns are:

1. Duplication: it's harder to know that you're getting all calls.
2. If you have foo = diverging_fn(), we need to still consider that a "write" to foo in a logical sense (i.e., for the purposes of borrowck). To do that under the approach of this PR, we'll need some marker that foo has been initialized, since DivergingCall no longer has a destination.

Basically, I'm not sure if the code for handling calls vs diverging calls will wind up being so very different in other passes. But it's a bit hard to know just now. A compromise might just be to introduce an enum into the call that is either NormalCall(BasicBlock, BasicBlock) or DivergingCall(BasicBlock).

In any case, let me read further before reaching final judgement.

[nagisa]

As I mentioned on IRC, I'm not sure if I think that splitting out "diverging call" into its own terminator is a good idea. My concerns are:

The last commit contains conversion to inner-enum, like you proposed on IRC. Feel free to compare.

[nagisa]

Comments on nagisa@0c7d57d are yet to be fixed.

---

EDIT: changed/fixed in nagisa@1c2f0d8. @nikomatsakis the code still looks equally ugly to me, but not sure if it could be made any better.

[bors]

☔️ The latest upstream changes (presumably #30651) made this pull request unmergeable. Please resolve the merge conflicts.

[nikomatsakis]

In all those cases where I gave nits about exhaustive matches, we were just trying to handle converging cases -- might be that a helper function for extracting the converging cases would be good. OTOH, I guess this is why you split those cases into two to start with.

[nikomatsakis]

OK, so, as you say, this is a big PR, and I feel like I could go on pointing out nits forever. But I'd rather we land it and just hack and try to clean things up. Some of these commits get pretty involved, but that may just be unavoidable if we want to generate less naive IR. Calls are just complicated. :) Anyway, so I'm leaning now towards landing this PR and then trying to keep improving things. One thing which would be nice are some more test cases for calls that generate invoke, and in particular to exercise some of those edge cases paths (like loop { c = call(); }).

[bors]

☔️ The latest upstream changes (presumably #30602) made this pull request unmergeable. Please resolve the merge conflicts.

[nagisa]

@nikomatsakis rebased and comments addressed (I hope I didn’t miss any). I added a few more tests as well.

[nikomatsakis]

r=me modulo final nits (in particular, the test with graphviz attribute should really be fixed)

[bors]

💔 Test failed - auto-win-msvc-64-opt

[bors]

☔️ The latest upstream changes (presumably #30492) made this pull request unmergeable. Please resolve the merge conflicts.

[Manishearth]

@bors r=nikomatsakis

[bors]

📌 Commit 36b3951 has been approved by nikomatsakis

[bors]

⌛️ Testing commit 36b3951 with merge d5ac1a1...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

[solson]

Why clone here instead of returning Option<&Lvalue<'tcx>> and letting the caller decide if it needs to clone?

[nagisa]

There’s two reasons, mostly, I had in mind:

1. Cloning Lvalue is very cheap most of the time (i.e. when Lvalue is not a Projection);
2. There’s users who want &mut lvalue and there’s users who want &lvalue. Returning a value allows to make either one easier when pattern matching (ref vs ref mut).

On the hindsight, I think this might actually be a bug to return destination by value in some cases which I didn’t think about before, thus I’ll submit a patch in a moment making these return a mutable reference instead.