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)
- change prerequisites for generating equals/hashCode/toString in a data class:
previously they were generated if the corresponding method is trivial (i.e.
it comes from kotlin.Any), now we're generating it always unless it'll cause
a JVM signature clash error (see KT-6206)
- use static KotlinBuiltIns.isXxx methods to compare types instead of checking
against descriptors loaded from certain built-ins instance, this is quicker
and more correct in environments where several built-ins are possible
- don't use isOrOverridesSynthesized, it's not relevant for
equals/hashCode/toString because functions with these names are never
synthesized
#KT-6206 Fixed
Preserve static initialization semantics for parts by introducing a special "clinit trigger" class.
Insert "static initialization trigger" call to every method of a part class, remove this call on inline.
Always mangle names for private functions in multifile class parts to avoid resolution clashes on inheritance.
NB in codegen tests initializers for all non-const vals are wrapped in 'run { ... }',
so that the initializer is not a constant expression, and some static initialization code should be generated.
Denis Zharkov