@rdmarsh2 has been working on various queries and libraries on top of the IR, and has pointed out that having to always refer to an operand of an instruction by the pair of (instruction, operandTag) makes using the IR a bit clunky. This PR adds a new `Operand` IPA type that represents an operand of an instruction. `OperandTag` still exists, but is now an internal type used only in the IR implementation.
This is motivated by test performance; IR compilation happens separately
for each test and takes a bit over a minute, so combining these 8 tests
saves about 10 minutes of test running.
The IR for the conversion to bool results in a comparison where the left
hand side is not the result of any expression in the AST, so they can't
be usefully converted back to the AST
For ease of reviewing, I've checked in the .expected files from the
AST-based guards library. The next commit accepts output for these tests
and adds tests that use getAST rather than the translation layer.
It turns out that when building aliased SSA IR, we were still keeping around the Phi instructions from unaliased SSA IR. These leftover instructions didn't show up in dumps because they were not assigned to a block. However, when dumping additional instruction properties, they would show up as a top-level node in the dump, without a label.
Also exclude templates as their names are not canonical.
The test changes in `isfromtemplateinstantiation/` are the inverses of
what we got in 34c9892f7, which should be a good thing.
These tests exercise the problematic cases where a variable can appear
to have multiple types because of how we fail to account for qualified
names when comparing type names.
This makes two changes to how example exprs are selected. Example exprs
are now ordered separately by each piece of the location, rather than by
stringifying their location. Second, UnknownLocations are now ordered
after locations with absolute paths, by using "~" in the lexicographic
comparison of absolute paths. I think this works on both POSIX and
Windows systems, but it's possible I'm missing a way to start an
absolute path with a unicode character.