"Floating point" refers to both `double` and `float`, and is also used by
the JLS in this way. Therefore the old CodeQL class name for `float` literals
was misleading.
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
I introduce AnyEqualsExpr for either reference or value equality and AnyEqualityTest for the same concept including not-equals operators, and use them wherever the written QL clearly doesn't care about the difference between reference and value comparison, typically because it is concerned with testing against null or against a primitive constant.
- 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.
It is possible for a call to have both, e.g. the `arg.ext()` call in:
class Class1 {
val y = 4
}
class Class2 (val arg:Class1) {
val x = 3
fun someFun() {
arg.ext();
}
fun Class1.ext() {
val z = x + y
}
}
