When calling vararg methods with a generic vararg type without
passing explicit parameters, we have to allocate an empty array
of the right type. We failed to do so previously, as we did
not take the type arguments for the dispatch receiver into
account.
Ignore this directory in JVM IR boxAgainstJava tests (similarly to box
tests) so that we can ignore the fact that this test doesn't pass in
JVM_IR, since it shouldn't.
The root problem is the fact that ConstantExpressionEvaluator returns
null for values such as infinity and NaN loaded from cls psi (see
IDEA-207252). This commit simply reverts a part of 8ab9226805 where we
started to compute default values more often than needed. In
LazyJavaClassMemberScope, we only need to check whether or not there
_is_ a default value, not compute its value.
#KT-29792 Fixed
Most of these tests used this directive as a way to opt in to a new
language feature, and most of those features are already stable for a
long time, so no opt-in is needed. Some other tests used the directive
to opt out from a language feature, replace those by the `LANGUAGE`
directive. One test used the directive to test behavior that actually
depended on the API version; use `API_VERSION` directive there instead.
See how we translate raw types to Kotlin model:
RawType(A) = A<ErasedUpperBound(T1), ...>
ErasedUpperBound(T : G<t>) = G<*> // UpperBound(T) is a type G<t> with arguments
ErasedUpperBound(T : A) = A // UpperBound(T) is a type A without arguments
ErasedUpperBound(T : F) = UpperBound(F) // UB(T) is another type parameter F
Stack overflow happens with the following classes:
class A<X extends B> // NB: raw type B in upper bound
class B<Y extends A> // NB: raw type A in upper bound
when calculating raw type for A, we start calculate ErasedUpperBound(Y),
thus starting calculating raw type for B => ErasedUpperBound(X) => RawType(A),
so we have SOE here.
The problem is that we calculating the arguments for these raw types eagerly,
while from the definition of ErasedUpperBound(Y) we only need a type constructor
of raw type B (and the number of parameters), we don't use its arguments.
The solution is to make arguments calculating for raw types lazy
#KT-16528 Fixed
It works only for Java methods and it's purpose is Java overridability rules emulation,
namely distinction of primitive types and their wrappers.
For example `void foo(Integer x)` should not be an override for `void foo(int x)`
#KT-11440 Fixed
#KT-11389 Fixed
Mads Ager