This fixes some type argument mismatch errors caused by a captured type
being approximated and then captured again.
Some places need to be adapted to work with captured types that
previously only worked with approximated types.
#KT-62959 Fixed
Previously when unsigned arrays were passed as vararg in a named form the necessary spread element wasn't generated, which resulted in a compilation error.
^KT-63514 fixed
- Actualize muted K2 tests
- Actualize muted K1 tests with module systems because legacy Wasm test
infra had no respect for "// MODULE: ..." test directives
This only affects JVM IR, and this is similar to how this was done in
the old JVM backend in `CallBasedArgumentGenerator.generateVararg`.
#KT-52146 Fixed
We are going to deprecate `WITH_RUNTIME` directive. The main reason
behind this change is that `WITH_STDLIB` directive better describes
its meaning, specifically it will add kotlin stdlib to test's classpath.
ProhibitAssigningSingleElementsToVarargsInNamedForm is enabled from 1.3
so there is no need to make FIR accepting single element passed through
named arguments.
In addition, we may want to report only
ASSIGNING_SINGLE_ELEMENT_TO_VARARG_IN_NAMED_FORM_FUNCTION and not arg
type mismatch. But FE1.0 is reporting both so I am following it. If we
want to remove the redundant report, we will probably want to remove
FirNamedVarargChecker and report during resolution as a cone diagnostic.
Creating a new array (and copying data into it with System.arraycopy)
doesn't work in generic case, because the actual array class depends on
call site.
In tests merged from boxAgainstJava in 29b96aa1, some directories were
named slightly differently compared to box, e.g. "property" vs
"properties", "varargs" vs "vararg". This change renames these, moves
some of the tests to more fitting directories, and also renames
"visibility" to "javaVisibility" because it's about Java visibilities
specifically.
When calling a generic Java generic method with vararg parameters with empty
vararg, incorrect array creation instruction was generated for primitive type:
NEWARRAY T_INT instead of ANEWARRAY java/lang/Integer. Here for Java method
public static <T> void takesVarargOfT(T x1, T... xs) {}
corresponding vararg parameter was considered to be of type 'Array<T>?',
which is not a non-null array type, so, NewArray intrinsic failed to generate
proper bytecode.
Fun fact: this is not actually validated when loading the class; and
even when compiling a java file against a class file that does this,
only javac 9 has a check (1.8 and before simply crashes with
NullPointerException somewhere deep inside the compiler).
Introduce MetadataSource as a way to store the original descriptor for
any element (before any lowerings) and maintain it until the end of the
codegen where it's used in generating the metadata. Note that JVM
signatures written to the metadata are formed from the _resulting_
generated elements, not by mapping the original descriptors.
Some corner cases are not supported yet, namely properties declared in
companion objects, synthetic methods for property annotations,
JvmPackageName, etc.
#KT-29119 Fixed
Kirill Rakhman