These three methods are conflicting with existing extensions,
thus the behavior might be changed when switching to JDK 11
Probably, it's worth revisiting our strategy here,
e.g. by blacklisting all new methods in
#KT-24974 Fixed
Suspend functions and callable references to suspend lambdas are already
supported.
Support callSuspendBy of suspend function of big arity.
#KT-24854: Fixed
Avoid name clashes in cases such as
inline class Login(val login: String)
inline class Password(val password: String)
fun validate(login: Login) { ... }
fun validate(password: Password) { ... }
Only use the other setType that takes an instance of
ReceiverParameterDescriptor. This will make sure that call sites can
use correct receiver annotations
This reverts commit ba111d58ae.
The reverted commit only makes sense after a bootstrap step after
advancing the metadata version, which has not yet happened in master,
but did happen in 1.3-M2, where this commit was supposed to end up
This has no effect on the correct code currently, but will help in
debugging when changing the serialized metadata for properties.
For example, if after some change an empty propertySignature extension
is written for Property (it's possible for PropertyDescriptor without
getter or setter and without backing field), we now won't try to read a
missing getter message when loading annotations on property getter. In
protobuf, reading a missing message will result not in an exception, but
in a "default" message being returned, which makes no sense in our case
because it would simply be read as a getter signature with both "name"
and "desc" equal to 0 (i.e. the first entry in the string table)
Replace ones from org.jetbrains.kotlin package with new annotations from kotlin.annotations.jvm.
No need to copy them to compile kotlin-reflect anymore.
Then simplify reflect project more: no sources — no need to pack its direct output.
Move parts of the logic to the only places where they're needed:
checking for public/final/val is only needed in
JvmFieldApplicabilityChecker, checking the proto flag is only needed in
reflection, checking the JvmField annotation presence is only needed in
backend
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
There's still some blind spots:
- Covariant overrides in Java (KT-25036)
- Current implementation assumes that when language version is 1.3 every suspend function
reference only release-coroutines-package Continuation
(we need to check if it's a correct statement)
#KT-24848 Fixed
#KT-25036 Open
Introduce a method to create org.jetbrains.kotlin.load.kotlin.MemberSignature directly from JvmMemberSignature.
Create JvmFunctionSignature from JvmMemberSignature.
They are hardcoded to avoid having dependency from android.jar on
our annotations' jar with UnderMigration.
Even while it could be a compile-only dependency we need to make sure
that annotated types are read properly without RecentlyNonNull/RecentlyNullable
in the classpath
#KT-24278 Fixed
Generate continuation type as kotlin.coroutines.Continuaion. This code will
fail at runtime since there is no stdlib backing this change yet.
However, in order to generate compatible stdlib we need a compiler, which
generates continuation type as kotlin.coroutines.Continuation.
Thus, firstly we support the change in the compiler, make it bootstrap
compiler and only then change stdlib and tests accordingly.
#KT-23362
Dmitry Petrov