Recently second javaType function appeared in reflect and
now FIR can't correctly resolve the code :(.
Will be fixed after annotation deserialization full support
classes, instead of MemberScope.
The primary motivation was to fix issues around type-mapping for inline
classes in FIR, which uses wrapped descriptors that have empty
MemberScopes.
1. Postpone the computation of the signature for property
reference getters for extension properties until codegen time.
2. Generate metadata for static replacement functions instead
of the original functions.
This is possible now because after 3a9b94235f, 0423d0f41e and
5341de253f, all top level functions/properties in sources and in
binaries have a corresponding containing facade class
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)
Getter of a primary value of an inline class belongs to the box class.
Its arguments should not be unboxed when the method is called.
However, its result might require boxing if it's an inline class value.
When we have an internal primary value, there's no getter method.
In fact, we can use box/unbox methods for inline class directly
(don't forget to box the result, it may be an inline class type value).
#KT-26748
Also fix a bug where nullability of the assigned value was not checked
in ClassCompanionFieldSetter because it wasn't a subclass of FieldSetter
where this check occurred
The implementation is a bit obscure because this worked on JS since
Kotlin 1.0 and we should not break that; however, on JVM, a diagnostic
will be reported with old language/API version
#KT-25241 Fixed
Jinseong Jeon