* Move FinallyBlockLowering to common part
* Fix catching of dynamic exception
* Fix bridges for suspend functions
* Disable explicit cast to Unit
* Run lowering per module
* Update some test data
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
Caused by 4266e50be8 and 8ccbbf71ec. Previously it worked because we
used hardcoded signatures of equals/hashCode/toString and always looked
them up in java.lang.Object
#KT-25404 Fixed
There are cases when members deserialized from JVM classes have no JVM
signature in the proto. For example, if a member is inherited from a
built-in class (such as Map.getOrDefault in some Map implementations),
or if a member is synthesized in the compiler front-end and back-end
separately (such as enum values/valueOf). In these cases, we'll use the
naive type mapping to try to recover the signature.
#KT-16616 Fixed
#KT-17542 Fixed
The only client of this data is reflection, and since anonymous objects
do not have constructors in the source code, they shouldn't in
reflection as well
#KT-20442 Fixed
The change in DescriptorSerializer is needed so that serialized protos
of enum entry classes which are resolved in sources
(LazyClassDescriptor) and are deserialized from binaries
(EnumEntrySyntheticClassDescriptor) are the same. There are tests on
incremental compilation in JS that check that the serialized proto is
exactly the same after rebuild and after an incremental build.
#KT-22048 Fixed
The problem was that in JvmSerializerExtension.writeLocalProperties, we
only serialized metadata for local properties, but indices generated in
MemberCodegen.generatePropertyMetadataArrayFieldIfNeeded were among all
delegated properties in the class (not only local). This behaved
incorrectly as long as there was a local and a non-local delegated
property in the same class. For example, if there were 5 non-local
properties and then one local, that local property would get the index 5
and the synthetic signature "<v#5>". But there would only be one
Property entry in the metadata, and so reflection would fail here trying
to load the 5th element of the list which contains only one element.
Now, the index for a local delegated property is computed only as the
number of _local_ delegated properties above it in the class, i.e. the
first local delegated property gets index 0 (and synthetic signature
"<v#0>"), the next one -- index 1, and so on.
#KT-23413 Fixed
Codegen generates static backing fields for object properties.
They are initialized in class constructor but some of them are final static
and such access is prohibited in specification but it's allowed in
java bytecode <= 1.8. Such access in 1.9 bytecode cause
"IllegalAccessError: Update to static final field Object.INSTANCE
attempted from a different method (<init>) than the initializer method <clinit>"
Added additional hidden field in interface companion to pass out
companion instance from <clinit>.
#KT-15894 Fixed
The problem is that now that the local delegated property metadata is in
the $$delegatedProperties array of the containing class, the access to
it from code calling an inline function with a local delegated property
is illegal.
Currently it seems to be a lot of work to support this rather rare case
properly (see the comment in ExpressionCodegen.getVariableMetadataValue)
so we postpone it and return the old behavior of using the anonymous
KProperty subclass for metadata
Class.getMethod does not return protected methods from super class, so
we invoke getDeclaredMethod on each super class manually instead
#KT-18480 Fixed
The previous condition that checked if we'd skipped any optional
parameters didn't work when number of parameters > 32 because the number
of bit masks in that case was more than one
#KT-18404 Fixed
#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
Svyatoslav Kuzmich