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
This can happen e.g. if all supertypes were on the cycle (A : B, B : A)
-- then SupertypesLoopChecker will cut all supertypes that are on cycle,
leaving set of supertypes empty.
Some clients in the compiler are not ready to work with empty list of
supertypes -- notably, CommonSupertypes.
^KT-23029 Fixed
We're suspecting that the culprit of such errors is race condition on
'supertypes' in AbstractTypeConstructor, when it is created using
'LockBasedStorageManager.NO_LOCKS'
Treat them like lambdas. This means:
1) Like local suspend lambdas, which become "non-suspend" after creating
jvmSuspendView, they do this as well
2) They both are generated with the same codegen.
3) They are treated differently only on front-end side.
#KT-20364: Fixed
The standard way of loading resources with built-ins metadata from the
current class loader no longer works in the modular mode on Java 9
because the current class loader is for module 'kotlin.reflect', but the
metadata is located in the module 'kotlin.stdlib'. On Java 9, we now use
the class loader of 'kotlin.stdlib' to load these resources.
#KT-21266 Fixed
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Affected cases:
- return type for suspend lambda
- aliased type in type alias declaration
- using type alias instead of aliased type in declarations
#KT-23345 Fixed
#KT-21696 Fixed
The problem is coming from the fact that `AnnotationTarget.VALUE_PARAMETER` is mapped to receiver parameter and to value parameter, but annotation with use-site target `receiver` can be used only on type reference of receiver parameter
Previously, if both type and typeId messages were missing (for example,
ProtoBuf.Function.returnType/returnTypeId) because of some bug, the
behavior was unpredictable because a type with id 0 from the type table
would be returned, which could be a completely irrelevant type. This is
an incorrect situation and we should report a diagnostic instead.
Temporarily throw an exception instead, since this only affects how the
compiler works on bad metadata
There are two reasons for this. First, this class will be used in the
metadata reading library which should not have dependencies on lots of
compiler stuff JavaToKotlinClassMap depends on.
Second, it was easy to accidentally break the deserialization in old
compilers by adding another mapping to JavaToKotlinClassMap. This was
possible because ClassMapperLite is used to decide whether or not the
JVM signature is "trivial" and should be written to the metadata (at
JvmSerializerExtension.SignatureSerializer.requiresSignature). If the
signature is trivial but mentions a type added in JavaToKotlinClassMap
in the new compiler, the old compiler will not be able to load the
signature correctly. See the comment on ClassMapperLite for more
information
Alexander Udalov