This works in many cases, however, it is incomplete since there
are cases where classes are extracted to top-level and therefore
reparented. Therefore, we lose the information about the function
class are nested inside.
Since functionFromStdlibSingleFileFacade.kt was introduced, lazyOf was
also moved to a multifile class, so we're using another function to test
that reflection on a single file package facade from stdlib works
* In blocks, discard the result of any statement that has a return
type other than void. This was previously done by wrapping each
statement into an "implicit Unit conversion" that was actually
compiled down to a stack pop instead. If an expression happened to
already have type Unit, however, such a conversion was not inserted,
resulting in a stray reference on the stack. These conversions are
now redundant and should probably be removed.
* In assignments and non-exhaustive conditionals, materialize a Unit
on the stack to avoid depth mismatches that trip up the bytecode
validator. Because such expressions are generally used at block level
(and, indeed, the frontend will reject a non-exhaustive conditional
used as an expression), combined with the above change this results
in no additional GETSTATIC opcodes, as they are immediately removed
by the peephole optimizer.
This was broken in c1ab08c8ce where we started to represent KClassValue
as a ClassId of the referenced class + number of times it's been wrapped
into kotlin.Array. Local classes do not have a sane ClassId, so in this
change we restore the old behavior by representing KClassValue with a
sealed class value instead
#KT-29891 Fixed
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)
In JDK 9, Class.simpleName changed behavior for local/anonymous Kotlin
classes (see KT-23072), this is why we now check for both variants of
the name in tests. Also, the format of annotation arguments changed a
little, where float parameters no longer have the trailing "f", and
class literals are rendered with ".class" at the end
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
Use only getDeclaredMethod/getDeclaredConstructor instead. The reason is
that getMethod/getConstructor only finds public-API (public or protected
on JVM) declarations, and to determine if a declaration is public-API in
the class file we used isPublicInBytecode, which was trying to load
annotations on the declaration to see if it was InlineOnly, and that
required lots of time-consuming actions and worsened the stack trace (as
can be seen e.g. in KT-27878). In fact, the implementation of
Class.getMethod is not supposed to do anything complicated except
loading annotations from each superclass and superinterface of the given
class. Doing it in our codebase simplifies implementation and probably
improves performance
Only invariant array projections and non-null element types will be
supported soon (see KT-26568), so it makes no sense to store the
complete type in KClassValue. What we need is only the ClassId of the
class, and the number of times it's wrapped into kotlin/Array, which is
exactly what ClassLiteralValue represents.
This change helps in decoupling annotation values from
descriptors/types. The only constant value that depends on descriptors
is now AnnotationValue.
#KT-26582 Fixed
Both for callables obtained via reflection API (KClass.members etc) and
for callables obtained via ::-references, the instance parameter is now
the class which was used to construct the type at the left-hand side of
the reference, NOT the class where the callable is originally declared
as is known at compile-time. The reason is to reduce the difference in
behavior of KCallable.call vs FunctionN.invoke: the latter always
required the subclass instance for a fake override, and it's reasonable
that the former would require it as well.
Note that in Java reflection, behavior could differ in a similar case.
For a simple fake override, Class.getMethod would return the method
declared in the base class and that method will accept instances of the
base class in invoke. However, it's difficult to rely on this behavior
because if there's a bridge for a fake override in the derived class
(e.g. when overridden members have different signatures), the returned
Method object is accepting the derived class as the receiver. This just
confirms the fact that Java reflection operates on a different level of
abstraction, namely JVM methods in .class files, which is not applicable
to our use cases directly. Another reason not to replicate Java
reflection's behavior is the uncertainty as to which member is returned
in case there are several in the hierarchy for a given fake override:
see the "otherwise one of the methods is chosen arbitrarily" note in
javadoc on Class.getMethod.
#KT-24170 Fixed
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
