#KT-10397 Fixed
According to JVMS (p. 4.3.4) inner classes should be separated with `$` in generic signature.
Note that in Java, inner types separated with `.` after first parameterized type, and now we preserve the same behaviour. See tests for clarification.
This patch mutes the following test categories:
* Tests with java dependencies (System class,
java stdlib, jvm-oriented annotations etc).
* Coroutines tests.
* Reflection tests.
* Tests with an inheritance from the standard
collections.
Before this change such wrapping happened only during coercion,
i.e. when a call-site expected a KClass instance.
But when call-site expects Any, for example, no wrapping happened,
and raw j.l.Class instance was left on stack.
The solution is to put wrapping code closer to generation of annotation's
method call itself to guarantee that necessary wrapping will happen.
#KT-9453 Fixed
The main problem here is that moduleName that is being passed to KPackageImpl
is useless: as can be seen in
ClosureCodegen.generateCallableReferenceDeclarationContainer, the name of the
current module is always written to the class file for a callable reference,
not the name of the module of the referenced declaration. This resulted in
reflection not loading the correct .kotlin_module file and subsequently not
finding the required file facade for a top-level function.
The commit does not fix the issue with the incorrect module name written in the
back-end, but workarounds it. It turns out, reflection can figure out the name
of the module of the referenced declaration itself by parsing the header from
the given java.lang.Class object for a single-file/multi-file package facade
and extract the package_module_name protobuf extension. Similar code was
already there in Member.getKPackage() in ReflectJvmMapping.kt but it did not
support multi-file classes, of which there are a lot in the standard library;
this is now supported
#KT-12630 Fixed
#KT-14731 Fixed
These two functions are supposed to fix an inconvenience in the design of
KProperty{1,2}.getDelegate for extension properties, where you have to pass an
instance of the extension receiver which is going to be completely ignored
#KT-8384 Fixed
Inline functions with reified type parameters are generated as private (see
AsmUtil.specialCaseVisibility), so we should treat them as "declared" in
reflection to look them up via getDeclaredMethod, not getMethod
#KT-14721 Fixed
Use the same approach that is used for creating function type classes
(Function{0,1,...}) + add Cloneable to supertypes of Array and primitive arrays
#KT-5537 Fixed
The only place where their get/set methods were used was in
KPropertyNImpl.Getter.invoke, and it's fine if that results in a reflective
call instead (KPropertyN#getter is not available without kotlin-reflect.jar
anyway). The test data has been changed because a package local Java field is
not accessible via reflection
Generation of callable reference's signature in codegen should use the same
mechanism for obtaining the signature as the runtime in RuntimeTypeMapper,
namely DescriptorUtils.unwrapFakeOverride(...).original
#KT-13700 Fixed
Both primitive int and wrapper type java.lang.Integer are represented by the
single type kotlin.Int in Kotlin, so inequality between the corresponding
KClasses was confusing here. To keep the old behavior, one may call 'k1.java ==
k2.java' instead of `k1 == k2`
#KT-13462 Fixed
As in KClassifier.createType and everywhere in the compiler, specify arguments
for the innermost type first. This is more convenient to use because generally
the construction/introspection of such type starts from the innermost class
anyway (i.e. something like generateSequence can be used, without the need to
call .reverse() in the end)
Mikhail Zarechenskiy