Without this directive the test can't be compiled by Kotlin/Native, because the box() function which is annotated with @ExperimentalContracts is called from the generated test runner source code that itself is not marked by this annotation.
Incorrect builder was used at line 269, which led to non-sensible type
in `IrClass.thisReceiver` for function types, such as
`SuspendFunction1<SuspendFunction1, SuspendFunction1>` in the linked
issue.
Avoid creating types manually completely to simplify this code and fix
the bug.
#KT-49168 Fixed
1. Move jsInteropFunctionsLowering after callable reference lowering,
so it can continue to deal with just functions and function calls.
2. Generate lowered closure class in JsInteropFunctionsLowering because
They were added in e4702bf438 and a08cf59017 but in fact they are not
needed on JVM until there are JVM-specific extensions in the metadata.
Moreover, there was a typo in JvmValueParameterExtensionVisitor's
superclass (see https://github.com/JetBrains/kotlin/pull/4613).
^KT-48816 Fixed
Native compiler uses lazy IR for declarations provided by cinterop.
The problem: `FakeOverrideBuilder` requests super types during
type checking, accessing `.owner` for them. So if a type and super type
are represented as lazy IR, and lazy IR generation is not enabled yet,
then the super type symbol won't be bound by this moment, and the access
will fail.
This happens in KT-48816: fake override builder tries to access `.owner`
for `IrClassSymbol` of `NSObject` (super type of `NSDate` and `NSUUID`).
Fix this by enabling lazy IR generation before building fake overrides.
This shows up in annotation instantiation tests where we need
to make sure to generate a property on the annotation implementation
class for such properties.
This artifact was used to build compiler artifact during each project
build, which is not needed for running compiler tests. Removal of
this artifact from build chain reduces time of build for ~3 seconds
which is a lot for rebuilds after minor changes (which are usually
take only few seconds)
This convention seems to be more robust against clashes against user
specified source set names. We could potentially foresee users to
use "cinterop" as source set name, but the pattern
$sourceSetName-cinterop seems robust enough.
^KT-49596 Verification Pending
Dmitriy Dolovov