For the same reason as in the previous commit: descriptors are cached
via weak references in moduleByClassLoader.kt and can be
garbage-collected at any point. So different instances of KParameterImpl
representing the same parameter may store different instances of
descriptors.
Descriptors are cached via weak references in moduleByClassLoader.kt and
can be garbage-collected at any point. So relying on identity of
descriptors in KTypeParameterImpl is dangerous because the same type
parameter can be represented by different descriptors. For example, the
test equalsOnFunctionParameters.kt was flaky before this change because
of this issue, and that could be reproduced by running it a few hundred
times in the same process.
Instead, use the type parameter's container (which is either KClass or
KCallable) and name, in equals/hashCode. KClass and KCallable already
have equals/hashCode independent of descriptors, so this works in case
the descriptor is invalidated.
Class.getClassLoader returns null for classes loaded by the system class
loader (the one used to start the application). In this case we need to
use ClassLoader.getSystemClassLoader. We already have an extension
`safeClassLoader` specifically for this purpose in reflection.jvm, but
forgot to use it in d59f2bcc80.
#KT-37707 Fixed
The Android build pipeline can extract embedded proguard configurations
from dependencies and merge them automatically. This adds a conservative
proguard configuration to the kotlin-reflect JVM artifact in support of
that. This focuses mostly on just retaining what's necessary for
kotlin-reflect's own functionality to operate, but could be expanded if
community feedback discovers other good candidate rules.
With this in place - most Android projects using R8 or Proguard should
Just Work™️ with kotlin-reflect.
returns Unit. The reason is the same as in the previous commit.
If the callable is tail-call and its callee returns something other that
Unit and suspends, on resume the result of the call will not be Unit.
#KT-34703
Otherwise this brings incompatibility between kotlin-reflect 1.3.70+ and
kotlin-stdlib 1.3.60-.
This commit reverts the relevant parts of c164745301, 5c89f2fa54 and
896512f7cd.
These fields were originally non-volatile because of an incorrect
assumption I had at the time that a value was safely published if the
underlying object's class has at least one final field. This is true for
almost all values used in lazy/lazySoft: DeserializedFunctionDescriptor,
DeserializedPropertyDescriptor, KTypeImpl, java.lang.reflect.Field, etc.
But of course, this only means that the object was _safely initialized_
and not safely published via the non-volatile reference, where other
threads can still observe null, even after that constructed object was
leaked to the outer world by some other means and led to observable
changes in behavior.
This can fix some concurrency issues in kotlin-reflect. I wasn't able to
reproduce the problem in stress tests though.
move it into appropriate package and ensure that it gets relocated
properly in kotlin-reflect.jar
This change is needed to use the functionality that provides descriptors
from classloaders for scripts compilation.
There are two parts in this change:
1) Previously, we looked up $default methods with the incorrect
signature in supertypes. For example in defaultInSuperClass.kt, we'd
try to find a method foo$default with the signature `(B, String,
String, int, Object)` in the class A. Now we're modifying the array
of parameter types on each step if we're looking for a static
$default method, by assigning its first element to be the containing
class. This fixes cases when defaults come from a superclass.
2) For interfaces, $default methods are actually located in the
corresponding DefaultImpls class. Now we look up that class and
search for the $default method there. Note that this is needed
because of KT-33430. This fixes cases when defaults come from a
superinterface.
#KT-13936 Fixed
This fixes an issue in constructing annotation instances with array
class elements. For some reason, behavior of `ClassLoader.loadClass`
differs from `Class.forName` in handling arrays, namely:
* `loadClass("[Ltest.Foo;")` returns null
* `Class.forName("[Ltest.Foo;")` returns class for array of test.Foo
Overall, there doesn't seem to be any way to load an array class with
`CLassLoader.loadClass`.
We pass initialize=false to forName because this is the behavior of
ClassLoader.loadClass: it doesn't perform class initialization (e.g.
<clinit> is not executed).
#KT-31318 Fixed
`RuntimeTypeMapper.mapSignature` threw exception because the descriptor
for `clone` was created manually in CloneableClassScope and therefore it
didn't have a JVM signature as in deserialized descriptors, and wasn't
recognized as a Java method either.
#KT-22923 Fixed
Previously, we used a pretty roundabout way to load a MemberScope from a
single file facade represented by KPackageImpl, which involved going
through ModuleDescriptor, PackageFragmentProvider, PackagePartProvider
etc. The only advantage of this approach was that it sort of works
similarly as in the compiler, however mutable state in
RuntimePackagePartProvider and the fact that .kotlin_module files were
required for this to work diminished this advantage.
In this change, we load MemberScope from a KPackageImpl pretty much
directly, by using the existing method
`DeserializedDescriptorResolver.createKotlinPackagePartScope` and
caching the result in the new component PackagePartScopeCache.
#KT-30344 Fixed
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
Otherwise they might be garbage-collected before being made accessible
with `isAccessible = true` and the reflective call.
Also, compute BoxUnboxData in InlineClassAwareCaller right away, to
prevent storing a hard reference on the descriptor (all descriptors and
related data are stored by soft references in kotlin-reflect).
#KT-27585 Fixed
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
Alexander Udalov