That prevents the SILVerifier from printing the context, making it
hard to quickly produce test cases from logs.
Instead, just return the failure status to the SILVerifier so it can
do its diagnostic thing.
An assert or llvm_unreachable would also be fine in addition to the
normal SILVerifier diagnostics, but I don't think that's needed here.
The verification will now be as complete as it can be within the
capability of our SIL utilities. It is much more aggressive with
respect to boxes, references, and pointers. It's more efficient in
that it only considers "overlapping" uses.
It is also now wholly consistent with the utilities that it uses, so
can be reenabled.
We could probably go even further and remove the switch statement
entirely, relying on AccessPath to recognize any operations that
propagate addresses, boxes, or pointers. But I didn't want to
potentially weaken enforcement without more careful consideration.
Limit names to a straightforward and unambiguous statement of
purpose. They should not pose additional questions which can only be
answered by reading the code. Nuanced meaning belongs in descriptions
and code comments.
These are all examples that legitimately made reading the code very
difficult for me:
- LoadBorrowInvalidationChecker: what does "invalidation" mean in this
context? How does that extend the meaning of "checker"? How can
something ever pass a checker and not be invalid?
- constructValuesForKey outside of an ADT does not state purpose at all.
- wellBehavedWriteAccumulator: Raises questions about what writes are
included and the broader semantics of the parent function. It turns
out that well-behavedness is handled by the function's return value
and has nothing to do with the accumulator.
