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
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
Consider call chain `foo.bar.baz()` which has expected type `Int`
Elements `foo` and `bar` doesn't have expected type `Int`,
this is especially important in NI, because we use expected type for
candidate applicability
Strip everything after (and including) the first '-' character.
The previous approach of skipping the checks if "SNAPSHOT" is in the
version, is subsumed by the new one because "1.2-SNAPSHOT" now becomes
"1.2" with regards to the version requirement checks, which allows the
compiler to use the 1.2-only API
The root issue here is that when we have some cycle in scopes, the place
where we detect a loop depends on where we've entered that cycle.
Previously, we didn't know about cases where we enter scopes loop
through `ClassResolutionScopesSupport.scopeForClassHeaderResolution` =>
there were no need to handle recursion on `scopeForClassHeaderResolution`
carefully.
It seems that in some very narrow cases (launch of specific
inspection on specficic code with specific caches state), we do manage
to enter loop exactly through `scopeForClassHeaderResolution` (see
KT-23033), which causes exception.
^KT-23033 Fixed
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
#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
Fixes #KT-23153 for Kotlin 1.3
The problem was in the type check of expression type against expected type. When feature `AssigningArraysToVarargsInNamedFormInAnnotations` (KT-20171) appeared, expected type could be wrong, which led to failed type check
Toshiaki Kameyama