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.
With the new formulation, we can join on function and index at the
same time, leading to significant performance gains on large code
bases that use templates extensively.
This query gets optimized badly, and it has started timing out when we
run it on our own code base. Most of the evaluation time is spent in an
RA predicate named `#select#cpe#1#f#antijoin_rhs#1`, which takes 1m36s a
Wireshark snapshot.
This restructuring of the code makes the problematic RA predicate go
away.
The `InstructionSanity::duplicateOperand` predicate used `count` instead
of `strictcount`. The 0-case of this `count` was as large as the
Cartesian product of `Instruction` and `OperandTag`, which made
`duplicateOperand` take forever to compute on large snapshots.
On a snapshot of Postgres, evaluation of
`getNextExplicitlyInitializedElementAfter#fff#antijoin_rhs#1` took
forever, preventing the computation of the IR. I haven't been able to
reproduce it with a small test case, but the implementation of
`getNextExplicitlyInitializedElementAfter` was fragile because it called
the inline predicate `ArrayAggregateLiteral.isInitialized`. It also
seemed inefficient that `getNextExplicitlyInitializedElementAfter` was
computed for many values of its parameters that were never needed by the
caller.
This commit replaces `getNextExplicitlyInitializedElementAfter` with a
new predicate named `getEndOfValueInitializedRange`, which should have
the same behavior but a more efficient implementation. It uses a helper
predicate `getNextExplicitlyInitializedElementAfter`, which shares its
name with the now-deleted predicate but has behavior that I think
matches the name.
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.
