- 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
IrDeclarationOrigin.FILE_CLASS is used in CallableReferenceLowering to
generate correct declaration owner.
Many reflection tests start to fail with this commit because they are
now treating callable references to top level declarations as Kotlin
symbols and fail because there's no JVM signature for them; this is
fixed in subsequent commits (previously, they worked because without
Kotlin metadata, these files were treated as Java classes)
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.
Svyatoslav Kuzmich