Also move internal declarations from runtime.jvm module into new package
kotlin.coroutines.jvm.internal in stdlib
The necessity of these declarations being in built-ins is controversial,
but also it will complicate the migration of current coroutine runtime
to a separate jar if we ever need this
Suspend function call with a reachable (alive) begin marker and unreachable (dead) end marker
is an exit point for the corresponding coroutine.
It isn't a suspension point, and doesn't introduce a new state in the coroutine FSM.
- Determine if there are non-tail calls to getValue/setValue simply
by existance of such a property
(it might be too strict, but implementing more granular check may be rather hard)
- Change in ExpressionCodegen is relevant for provideDelegate,
that in case of local variables uses OnStack as StackValue
(see the comment near these changes)
#KT-15933 Fixed
1. JVM view of suspend accessors must be also an instance of AccessorForFunctionDescriptor,
thus `createSubstitutedCopy` should be correctly overidden.
2. accessibleFunctionDescriptor should unwap the initial suspend descriptor,
for the same reasons as for type aliases constructors and etc:
these descriptors are used as keys of the map of accessors, so
to avoid duplication for suspend view and initial suspend descriptor,
we always use the latter one as a key.
#KT-15907 Fixed
#KT-15935 Fixed
When the extension receiver of a named suspend function was marked as used
from the inner lambda, codegen used to throw a "Don't know how to generate outer expression for class" exception.
It may seem quite tricky, but currently for suspend lambda body
its extension receiver is treated as it's defined inside the relevant "doResume"
(there is an actual bytecode part that fills the relevant local variable)
The problem was that inside ExpressionCodegen for "doResume" of named
suspend function we couldn't determine that original function has
an extension receiver.
#KT-15821 Fixed
#KT-15820 Fixed
If all the suspension calls in a suspend function were "hidden"
under the for-convention (iterator/next/hasNext) calls,
control-flow didn't find them, thus supposing that there is no
suspension points and there is no need to generate a coroutine state machine
The solution is to add relevant calls to CFG
#KT-15824 Fixed
Do not report an error on enum entry without initializer if all parameters have default values
(error is still reported if there is no such constructor, or if the constructor call is ambiguous).
Record resolved call on KtEnumEntry.
NB is the enum entry has a corresponding subclass, we still have to generate the "default" constructor call,
because FE doesn't know about the platform-specific representation of that class and its constructors.
See also KT-14097, KT-15900
#KT-10711 Fixed
#KT-12802 Fixed
#KT-12964 Fixed
#KT-15439 Fixed
Analyze callable references in `dependent` mode, then complete them with
respect to expected types
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
See doNotCaptureSupertype test for clarification:
When resolving b.collect(toList()) we're building a common system with
two variables T and R.
The problem was that when introducing the constraint
C<T, Inv<T>> <: C<in String, R> we then were seeing the constraint
T <= in String, and add the constaint T=Captured(in String)
That lead to R=Inv<T>=Inv<Captured(in String)>, and after approximation
R=Inv<in String>, that is not the desirable result (Inv<String> suits here)
But the root problem was that we add captured constaint when projection was from supertype,
that seems to be wrong, and for example Java doesn't do that in the similar situation.
#KT-11259 Fixed
The problem is that code in the attached test led to VerifyError at runtime
because the Bar's uninitialized instance created in 'map' was being stored
to the field (leaked from the JVM point of view).
The actual problem was that after repeating visiting of NEW operation
we used to drop the set of already visited copy usages.
For clarification see the comment before 'processUninitializedStores'
#KT-15016 Fixed
Otherwise it breaks JPS assumptions, that leads to exceptions like:
Error:Kotlin: [Internal Error] java.lang.AssertionError: Couldn't load KotlinClass from /Users/jetbrains/IdeaProjects/KotlinPlaygroundBeta11/out/production/KotlinPlaygroundBeta11/Counter$both$1.class; it may happen because class doesn't have valid Kotlin annotations
at org.jetbrains.kotlin.build.GeneratedJvmClass.<init>(generatedFiles.kt:36)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.getGeneratedFiles(KotlinBuilder.kt:469)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.doBuild(KotlinBuilder.kt:241)
at org.jetbrains.kotlin.jps.build.KotlinBuilder.build(KotlinBuilder.kt:140)
...
ContinuationInterceptor companion object is named Key
CoroutineContext.Element property for key is named just key
AbstractCoroutineContextElement implements all of CoroutineContext.Element, including key
Denis Zharkov