The problem is that
`override fun remove(element: E): CollectionWithRemove<E>`
seems to be illegal from Java's point of view, while it's OK for JVM
These declarations have the same signature (return type is isgnored)
- override fun remove(element: E): CollectionWithRemove<E>
- override fun remove(element: E): Boolean
When we meet such declaration we choose random declaration for fake override in synthetic class
that may lead to signature clash
Previously its call sites needed to determine if the receiver type should be
ignored (e.g. if the reference is to static member or nested class constructor,
or if it's a bound reference), and 3 of 4 callers did it incorrectly. Simplify
this by passing the DoubleColonLHS instance everywhere.
Also rename it to createKCallableTypeForReference
#KT-12738 Fixed
#KT-12751 Fixed
#KT-12799 Fixed
As well as all other kinds of expressions
While it's not necessary in a sense that 'for' loop can not be plain expression,
i.e. it can't be an argument for safe-call etc., but laziness is still very convenient property.
E.g. within attached test they were generated twice in case of last expression
of coroutine block, because coroutine related codegen part is built upon
assumption that all expressions should be generated lazy.
A lot of additional work was required to support them:
- Suspension points are being identified by two markers
instead of one pointing to suspend function call
- Approach with replacing return type of suspend function does not work anymore.
So we decode suspension return type as an argument for begin marker
- It became necessary to perform variables liveness analysis
(see comment in org.jetbrains.kotlin.codegen.coroutines.CoroutineTransformerMethodVisitor.spillVariables)
Without this change internal error happens while inlining coroutine code with try/catch inside
Also get rid of hack with SKIP_MANDATORY_TRANSFORMATIONS_ANNOTATION_DESC
See comment within MethodAnalyzer for clarification
Instead of performing signature change during transformation
it's convinient to make just when generating corresponding call,
for example there is no need to think about default parameters as they just work as is
See comment above replaceSuspensionFunctionViewWithRealDescriptor for clarification
- Use proper class descriptor when retreiving continuation object (see previous commit)
- Use return type as VOID for such cases
- Load correct labels related to coroutine lambda from outer context
Before this commit context.getThisDescriptor() has been used, that was quite correct
until suspension happens inside inlined lambda (it has different this-descriptor)
Michael Bogdanov