Kotlin/Native codegen needs to deserialize all fields throughout the class hierarchy to build the proper binary class layout. That becomes impossible with the guard condition that prevents loading private top-level classes from another module in LazyIR (see https://github.com/JetBrains/kotlin/blob/2a4d8800374578c1aa9ec9c996b393a98f5a6e3b/kotlin-native/backend.native/compiler/ir/backend.native/src/org/jetbrains/kotlin/backend/konan/serialization/KonanIrlinker.kt#L701). The guard suits well for the partial linkage needs, but it causes the codegen to fail with `Unbound public symbol IrClassPublicSymbolImpl: [ File '/file/in/the/library.kt' <- private.top.level/ClassDeclaration|null[0] ]` error.
To prevent this the guard is removed. This does not influence the partial linkage in general except for the different error message being generated: `Function 'foo' can not be called: Private function declared in module <A> can not be accessed in module <B>` instead of `Function 'foo' can not be called: No function found for symbol '<symbol>'`.
#KT-54469
This fixes an issue where an actual class from an intermediate module
has more supertypes than its expect declaration which leads to a
false-positive resolution error because a type reference resolves to the
expect class. The fix is to sort the dependencies topologically from
"most actual" to "most expect" when creating the list of symbol
providers.
#KT-57369 Fixed
The problem was that we were using unenhanced constructors that still
might contain java type refs.
Basically, most of the `firClass.declarations` usages are unsafe in that
meaning.
The test is very complicated because to reproduce the exception there
should be some conditions met:
- MyClass should be compiled with K1, so it has `@EnhancedNullability`
annotation serialized (that is unnecessary, but don't do any harm)
- `@Nls` scope should be properly resolved, so enum entries are converted
to resolved type refs
- That leads to attempt to check if null-check might be needed to be
inserted and to failure at FirTypeUtilsKt.getCanBeNull
While this quite controversial to have this check being performed for
freshly created annotations calls, the problem with improper constructor
lookup anyway existed and fixed correctly.
^KT-57213 Fixed
Otherwise, when we come to `ClassCodegen.kt:173
for `GradleActionTest` and check
`FUN FAKE_OVERRIDE name:<get-project>`,
we then go to `JvmSignatureClashDetector.kt:37`,
and call `mapRawSignature(overriddenFunction)`
which ignores the original `@JvmName`.
It does so because it relies on the property copy
which forgets to copy the getter, but
`@get:JvmName` is stored in it.
Extra when-branches for `FAKE_OVERRIDE` are needed,
because otherwise the annotations would not
be copied in `Fir2IrDeclarationStorage.kt:723`.
Extra when-branches for `DELEGATED_MEMBER` are
needed, because otherwise the generated IR changes
in some tests. For example, see:
`FirLightTreeIrTextTestGenerated.Declarations.testKt35550`.
The `assumesBackingField`-related change is backed by
the `FirLightTreeIrTextTestGenerated.Stubs.testJavaEnum` test.
`this.body = null` ensures the resulting IR
matches K1.
The change in `FirImplicitBodyResolve.kt` is needed,
because otherwise the bootstrap compiler fails at
`:compiler:frontend:compileKotlin`,
but I didn't come up with a smaller test for it.
If we don't make an explicit accessor copy,
then when we later create a `Fir2IrLazyPropertyAccessor`
for the fake override getter, it's `fir` will
be a reference to the `FirProperty`, not `FirPropertyAccessor`.
That's why `DumpIrTreeVisitor` will render `IntrinsicConstEvaluation` as
a getter annotation as well.
`FirPsiIrTextTestGenerated.testDelegatedGenericImplementation`
renders type parameters from `<get-x>`,
because when assigning `extensionReceiverParameter`
of the setter `<set-x>` we come to
`Fir2IrClassifierStorage.kt:638`,
and in this cache there's the parameter with
the `<get-x>` parent.
Note that `typeContext.origin == DEFAULT` in
`getCachedIrTypeParameter`.
It's `DEFAULT` because at the line `Fir2IrDeclarationStorage.kt:335`
the `function` variable is `null` (because there's no setter).
The change in `declarationAttributes.kt` is backed
by the `FirPsiIrTextTestGenerated.testKt45853` test.
^KT-57104 Fixed
^KT-57432 Fixed
Merge-request: KT-MR-9210
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
We've muted some irText tests on JS in the previous commits because
test expectations in some tests are different when targeting JS.
AbstractKlibJsTextTestCase tests use a different logic:
they compare the dump of the deserialized IR with the frontend-generated
IR, not with the expectations in text files, thus muted tests weren't
actually failing.
Here we introduce a temporary fix, namely
a separate // IGNORE directive for klib tests.
When klib tests are moved to the new test infrastructure, there will be
no need to do this.
Dmitriy Novozhilov