Vararg parameter in reflection type is interpreted as covariant
array type against array in expected functional type and as
vararg element type otherwise. For instance having function
fun foo(vararg args: Int): Unit { /*...*/ }
reference ::foo can be passed against expected
(Int) -> Unit,
(Int, Int) -> Unit, etc.
In none of such cases type for parameter in foo's reflection type
should be changed to array.
However, against expected type (IntArray) -> Unit args' type
must become IntArray.
^KT-25514 Fixed
* Extract replacement of IrGetField/IrSetField into a separate
file-level lowering (should reduce the amount of work to linear in
the number of classes rather than potentially quadratic)
* Extract static backing field construction into JvmDeclarationFactory
and move that lowering after PropertiesToFields lowering to reduce
code duplication
* When referencing the companion itself, they should use the $$INSTANCE
field, not the (null until <clinit> returns) Companion field of the
interface.
* Interface companion init blocks should be made static.
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).
- don't box/unbox when value is known to be an inline class
- add unbox state when coroutine resumed
- correctly handle suspension in case of inline class
- add tests
Code in inline lambdas can call multifile part members. These calls are
replaced in GenerateMultifileFacades with the call to the facade member.
Previously this didn't happen though because the lambda body was removed
before the GenerateMultifileFacades phase, which led to
IllegalAccessError in the -Xmultifile-parts-inherit mode (because the
part class is package private in another package).
The problem was that we tried to generate an `$annotations` method for a
property declared in an annotation class. That method is final and has a
body, which is not allowed in annotation classes. Now we're generating
this method in the separate `$DefaultImpls` class as for properties in
interfaces.
Note that the added test still doesn't find any annotations because the
proper support is needed in reflection (KT-22463). Currently it only
checks that no VerifyError happens.
In addition to fixing getContainingDeclaration, change origin of
multifile facades to FILE_CLASS since the corresponding class descriptor
should also be skipped when computing containing declaration. This fixes
the problem with internal function calls in -Xmultifile-parts-inherit
mode (previously we incorrectly mangled the function name in
MethodSignatureMapper), and also fixes coroutine intrinsic calls when
compiling kotlin-stdlib with JVM IR. In the latter case, all intrinsics
(such as isBuiltInSuspendCoroutineUninterceptedOrReturn) are present in
sources, and were previously not detected as intrinsics by the code in
`generateInlineIntrinsic` because the FQ name didn't match: it had an
additional component for the file class name.
May happen when a function in an `expect` class is aliased through an
`actual typealias`; the matching declaration is filtered out in
`ExpectedActualResolver.findActualForExpected` as it has no source.
Call checker and declaration checker are used in order to preserve backward compatibility.
Attempt to use classifier usage checker was not good enouth,
since not all errors found with it would actually be reported before.
For example types and constructor calls don't cause supertypes to resolve,
so missing supertypes would not lead to errors in case they are the only use of class name.
Updated tests failing due to missing Java dependencies in superclasses.
Technically a backwards compatibility problem, as the new backend
*consistently* renamed `f$default` on `f` with `@JvmName("g")` to
`g` instead of `g$default`, so it all worked out. However, this
breaks when encountering libraries compiled with the non-IR backend.
Otherwise a local class in a field initializer or anonymous init block
is copied into each constructor of the containing class (because
InitializersLowering calls deepCopy).
Since the code structure no longer resembles the original source code
here, record a custom EnclosingMethod mapping before moving such
classes, and use it in codegen.
Resolves the interaction of @JvmOverloads annotations and
parameterless main methods.
In the following code, both mechanisms generate methods that
ultimately produce the signature `public static void main(String[] args)`
of which there can be only one (true in general of any signature).
```
fun main() { }
@JvmOverloads
fun main(Array<String> args, x: Int = 42) { }
```
This PR simply shuffles the lowerings around, letting parameterless
main methods detect the presence of the default overload produced by
the annotation.
Additionally, this PR improves the testing of parameterless main
methods by actual bytecode patterns, and not simple check for
successful compilation (as @sfs and I discovered, there are issues in
flagging an error on duplicate signatures on the IR backend).
Mark Punzalan