Visiting a MIR `return` should visit the return place too

[jonas-schievink]

The return terminator conceptually moves out of the return place _0, but this is not currently reflected by the visitor infrastructure.

This can lead to incorrect dataflow solutions for _0. For example, MaybeLiveLocals reports that _0 is dead before a return, which is wrong (it must always be live there). These don't currently cause any harm, since use of _0 is fairly limited, but they are an issue for destination propagation / NRVO, which can propagate _0 to arbitrary places in the function and needs to have correct information to do so soundly.

The simple fix of calling visit_local from within super_terminator_kind has the problem that the MutVisitor receives a &mut Local, but the local return reads from can not be changed. This can be caught with an assertion, but maybe there is a better solution for this?

cc @rust-lang/wg-mir-opt

[oli-obk]

This can be caught with an assertion, but maybe there is a better solution for this?

I think any alternative will be more complex than that simple assertion. Conceptually the TerminatorKind::Return should contain a Local which is always _0, but then we'd need to have assertions keeping that in place, so you don't gain anything.

I don't think we can generalize returning to allow using different places than _0, which is the only way we'd get around having to assert something somewhere.