Strategy: there is now a regular flow step from an instance-of LHS / switch expr to the pattern, 0 or more read steps corresponding to record pattern destructors, and then finally a normal SSA def/use step connecting the binding patterns to their first uses.
This will allow the extractor to emit class(id, ...) when all it knows about a class is its name, due to not having it available on the classpath. Previously it would have had to guess whether it belonged to @class or @interface, possibly introducing an inconsistency.
I opt to identify any syntactic initializer. These are broader in scope than Java's member initializers, which are necessarily context-free, whereas in Kotlin the primary constructor's parameters can be referred to.
* Extract varargs as if they are ordinary positional arguments
* Adapt the QL that distinguishes varargs from ordinary arguments to account for Kotlin's varargs which can occur in the middle of the arg list
* Add a test checking dataflow through varargs which doesn't work yet due to array-get and array-set not being extracted as IndexExprs
* Extract the special case arrayOf(*x) as a clone call, which is (equivalent to) the Java lowering of that operation
- Create a new operator representing an infix value [in]equality test, equivalent to Objects.equals(lhs, rhs)
- Continue to use simple equality where it is clearly possible at the callsite
- Note that ieee754equals is the same as Java's == and != operators
We might want to unify some of these in future, but doing that
correctly is easier than splitting them up correctly, so I've given each
one its own QL class for now.
I am not familiar with many of the libraries/queries that use CastExpr.
I've briefly looked at them and updated them in a way that looks
superficially reasonable, but some of the uses will probably want to be
refined later.
I'm not sure it's worth adding an entity to the database for them,
although that would allow us to use a 'case' in the dbscheme for
the different kinds.
There's no QLL support for this info yet.
