Turns out the two use cases the TODO worried about are already taken care of: `Unit` is replaced with `void` only in contexts where primitives can be used, and `List` and similar only have incompatible extension methods, which are declared by `CollectionsKt` not `List`. This is likely deliberate to enable the Kotlin <-> Java substitution to be implemented simply by kotlinc.
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
In particular, we now write full exception information, so we can
diagnose problems.
We were using `warn` to log errors in some cases, and generally using
lower-level functions than necessary. We now use the appropriate
functions. I've lost the distinction between e.g. ErrorHigh and ErrorSevere
in this, but we can add it back if it's important.
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).
When we have Kotlin:
class A {
fun foo(z: OB<G1, G2>.B<E1, E2>) {
val foo = z.someFun()
}
}
and Java:
public class OB<S1, S2> extends OC<F1, F2> {
public class B<T1, T2> extends OC<F1, F2>.C<D1, D2, T1, T2> {
}
}
class OC<U1, U2> {
public class C<X1, X2, Y1, Y2> {
int someFun() {
return 5;
}
}
}
the `someFun` call is to a fake override, and has 4 type arguments.
If we treat it as calling the real function, then 6 type are expected,
and we get IndexOutOfBoundsException when we try to reorder the
type parameters in orderTypeArgsLeftToRight.
So for now, we just extract the fake overrides, so that we at least
don't crash.
