This intrinsic was always calling the supplied suspend function
non-virtually, and this was hardcoded in the intrinsic generator.
Now this can be configured with `superQualifierSymbol` in the respective
IrCall, just the way this works with any other calls.
As a side effect, global optimizations now process this intrinsic more
correctly (before that, they didn't take the intrinsic generator into
account, and treated the call as virtual).
Previous implementation of startCoroutineUninterceptedOrReturn expected
that the receiver (i.e. the suspend function object to start) of type
SuspendFunctionN (i.e. suspend function type with arity = N) is also an
instance of FunctionN+1 (i.e. regular function type with arity = N + 1)
with proper convention.
While compiler tries to achieve that (for better compatibility with
Kotlin/JVM, by generating additional supertypes and methods for classes
implementing suspend function types), this doesn't work e.g. for
implementations defined in Swift.
Fix this by adding fallbacks for cases when the receiver is not
a FunctionN+1, while keeping the fastpath for default FunctionN+1
cases.
^KT-51043 Fixed
Make `createCoroutineUnintercepted` invoke
`startCoroutineUninterceptedOrReturn` when suspend function object is
not a `BaseContinuationImpl` (e.g. for a custom suspend function type
subclass), instead of using the copy of its implementation.
This change parallelizes marking by making each non-native Kotlin thread
mark its own view of the heap. To make this safe, we make flipping the
marking bit atomic which ensures that threads do not try to trace the
same objects.
Co-authored-by: Johan Bay <jobay@google.com>
Merge-request: KOTLIN-MR-423
Merged-by: Alexander Shabalin <alexander.shabalin@jetbrains.com>
If a suspend function is called from `autoreleasepool {}` block, this
might cause the autoreleasepool frame to be removed earlier than
expected. See https://youtrack.jetbrains.com/issue/KT-50786 for more
details.
^KT-50786 Fixed
Review: https://jetbrains.team/p/kt/reviews/6753
Meaningful semantic change was splitted into 5 commits to simplify the
change review. Sinle commit would be too big.
Why replace source to binary: to get rid of kotlin-reflect in Kotlin
plugin artifact KTIJ-22276
Note: Kotlin Maven artifacts (./gradlew publish) changed their
dependency on kotlin-reflect
Review: https://jetbrains.team/p/kt/reviews/6753
In the next commits, source dependency on kotlin-reflect will be
replaced with binary dependency. Thus, it won't be technically be a a
"module" anynmore. So I either have to rename "kotlinReflectModule" or
get rid of it. I decided to get rid of it (inline it) because there is
only one usage.
Review: https://jetbrains.team/p/kt/reviews/6753
I don't know why this settings.gradle.kts is needed. But I think that
it was needed before "kotlin-native merge into kotlin" times. (Pavel
Punegov says the same) I try to remove and if CI doesn't fail then I
will push it.
I need to drop settings.gradle.kts because I'm going to replace
kotlin-reflect dependency from source to binary in the next commits. And
before doing this refactoring I want to normalize all the dependencies
on kotlin-reflect.
Vladimir Sukharev