Change:
let (remap, layout, storage_liveness) = compute_layout(tcx, source, &upvars, interior, movable, body); <ins> let can_return = can_return(tcx, body); </ins> // Run the transformation which converts Places from Local to generator struct // accesses for locals in `remap`. // It also rewrites `return x` and `yield y` as writing a new generator state and returning

Discussion:
Tested with The following program which stores a generator in a static variable and then resumes it (no indirection / dynamic-dispatch involved): when fully optimized for the target () produces the following machine code for the function: This function resumes the generator stored in the static variable . The generator is extremely simple and contains no explicit panicking branches yet the machine code contains 2 panicking branches which are not necessary for memory safety (more on this later). If the program is slightly modified like this (semantics are not changed): Then is optimized to the following machine code, which is free of panicking branches: This second machine code (the one with 5 instructions) is what one would expect from the first version of the program. Changing the shape / complexity of unrelated code should not introduce panicking branches. The function decides which part of the generator body to execute based on the value of a discriminant. As of nightly-2019-11-04 the code generated for the function contains 2 "built-in" panicking branches, which are present in all generators: The first built-in panicking branch, which corresponds to discriminant , is used to panic a generator that has been -d beyond completion -- a generator that has reached a statement has reached completion. The second built-in branch, which corresponds to discriminant , is used to panic a generator that has been -d after panicking -- I'm not sure when this can occur in practice but looking at the compiler codegen unwinding is required to reach this "poisoned" state. However, neither of these situations can occur in the example. The discriminant of the generator can never become because it does not contain a statement in its body. Its discriminant can not become either because the target has been configured for meaning that unwinding is not supported at the codegen level ( functions are never generated). This can be confirmed by scanning the optimized LLVM IR produced by the compiler: the discriminant is stored in static memory () and the only values written to this memory are and . Naively, I would improve the MIR codegen by: Not producing the branch if the type of the generator is (or, I guess, any other empty type like ). This type indicates that the generator does not contain a statement. Not producing the branch if the target has set its option to .

Alternatively, one could check if the unwind-related function is generated and omit the branch if it's not generated. Relevant code: Does these seem like sensible fixes? Steps to produce the above machine code. This is not a minified repro because a certain complexity is required to get the inferior codegen -- trivial programs get properly optimized. <details</details
Do you want to fix this? It should be pretty easy. Don't emit the return case if there's no terminator in MIR. Don't emit the unwind case if there's no terminator in MIR.
I guess the thing is not true since unwinds are implicit and other terminators can unwind too. I guess skipping it if will suffice. This does mean that the generator transformation doesn't poison all the unwind paths currently, just . so that has to be fixed too.
The generator transformation could be fixed by inserting a basic block with just in it at the start of and change cleanup/unwind edges of terminators with to point to the new block.