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.
Rework backing field generation logic in PropertyCodegen to switch the
ClassBuilder instance for a multifile part to that of the corresponding facade
class. This became needed because multifile parts, and their metadata, are
generated _before_ the multifile facade class and otherwise we would never
record that there's a synthetic '$annotations' method for a const val and would
not write that to the protobuf message for the property.
See also bad83200
#KT-10892 Fixed
Denis Zharkov