swift

20479c96 - [move-only] Refactor CanonicalizeOSSALifetime::canonicalizeValueLifetime into an API that computes liveness and a second API that rewrites copies/destroys and fix up MoveOnly checkers to use it.

[move-only] Refactor CanonicalizeOSSALifetime::canonicalizeValueLifetime into an API that computes liveness and a second API that rewrites copies/destroys and fix up MoveOnly checkers to use it. For those who are unaware, CanonicalizeOSSALifetime::canonicalizeValueLifetime() is really a high level driver routine for the functionality of CanonicalizeOSSALifetime that computes liveness and then rewrites copies using boundary information. This change introduces splits the implementation of canonicalizeValueLifetime into two parts: a first part called computeLiveness and a second part called rewriteLifetimes. Internally canonicalizeValueLifetime still just calls these two methods. The reason why I am doing this is that it lets the move only object checker use the raw liveness information computed before the rewriting mucks with the analysis information. This information is used by the checker to compute the raw liveness boundary of a value and use that information to determine the list of consuming uses not on the boundary, consuming uses on the boundary, and non-consuming uses on the boundary. This is then used by later parts of the checker to emit our errors. Some additional benefits of doing this are: 1. I was able to eliminate callbacks in the rewriting stage of CanonicalOSSALifetimes which previously gave the checker this information. 2. Previously the move checker did not have access to the non-consuming boundary uses causing us to always fail appropriately, but sadly not emit a note showing the non-consuming use. I am going to wire this up in a subsequent commit. The other change to the implementation of the move checker that this caused is that I needed to add an extra diagnostic check for instructions that consume the value twice or consume the value and use the value. The reason why this must be done is that liveness does not distinguish in between different operands on the same instruction meaning such an error would be lost.