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)
...
- `invoke` method must always start a suspend functions
- For creation of coroutine that has not been started yet, there are
two special internal interfaces `SuspendFunction0`/`SuspendFunction1`
Fixed KT-14939: use expected receiver type when generating receiver code in get/set methods for bound property references.
Otherwise we have VerifyError for bound receiver 'null' of type 'Nothing?', which is mapped to 'java.lang.Void'.
TODO: proper equality comparison for property accessors ('x::prop.getter', 'x::prop.setter').
Do not generate stubs if there is no special bridge in the current class
- there are already Kotlin super class in hierarchy
- special bridge has the same signature as method itself
#KT-11915 Fixed
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
- don't do anything for interfaces because there's no point in generating
abstract methods which are already abstract in supertypes
- don't use getDeclaredFunctionByRawSignature, check function signature
manually instead
- don't use isOrOverridesSynthesized because 'toArray' is never synthesized
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.
