The warning in the extractor is inaccurate due to references to enclosing types' type parameters. A consistency query can check that the type parameter is indeed in scope exploiting broader knowledge of the enclosing types.
Turns out type aliases are always substituted by the compiler, with the `IrSimpleType.abbreviation` field indicating what the original alias was if any. Therefore we're already extracting the right types. This commit simply omits extracting a kt_type for a type alias that uses type parameters as this certainly won't work at present because we don't have IrTypes for the type parameters declared by the alias and used in its RHS.
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
If it is used by the compiler to implement the infix plus operator, resugar it and extract a `+` as Java would. If it is literally called by the user (e.g. `(if (x) then "not null" else null).plus(something)`), then extract a call to the real method Intrinsics.stringPlus (a two-arg static method).
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.
