Raw classes from the database that are incomplete and should be
represented by their complete twin are now allowed to be `Element`s for
performance reasons, but this commit prevents them from being `Type`s.
It was causing confusion in test results and might also cause confusion
in queries.
Also remove the charpred of ElementBase. This gets rid of many redundant
charpred checks. It means that incomplete classes from the db are now
`Element`s, which is maybe noisy but should not be harmful.
Together, these changes give a great reduction in DIL and should help
the optimiser. It brings the DIL of `UncontrolledFormatString.ql` down
from 43,908 lines to 35,400 lines.
We currently erroneously keep mentions of class instantiations, which
can lead to bad performance on template-heavy code bases. We never
want to link those anyway, so we can simply suppress them.
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.
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.
