We have `BackendKinds.IrBackend` for IR emitted by the frontend.
We need a different backend kind for IR deserialized from klibs.
We cannot use `BackendKinds.IrBackend` for that purpose, because we
cannot have two different `IrBackendInput` subclasses with the same
kind.
We need a different `IrBackendInput` subclass for deserialized IR
because the `IrBackendInput` for frontend-emitted IR contains some
properties like `sourceFiles` which don't make sense for
deserialized IR.
Since we now have two backend kinds for IR artifacts, we need to make
certain functions and classes in the test infrastructure generic
over backend kinds.
Note: the JsIrDeserializedFromKlibBackendInput class is not used
anywhere yet. We will use it in the coming commits.
`ManglerChecker` is a class that verifies that for each IR declaration
(except some, see its `needsChecking` property) its mangled name
(computed from IR) is the same as the mangled name computed from its
frontend representation — `DeclarationDescriptor` on K1 or
`FirDeclaration` on K2.
The way it does it is as follows.
On K1, `ManglerChecker` looks if the declaration has a true,
non-IR-based descriptor, it if it does, then it checks it
(see ManglerChecker.Companion#hasDescriptor).
On K2, since we don’t have any descriptors, `ManglerChecker` looks if
the declaration’s metadata property is `null` (because the corresponding
`FirDeclaration` is stored there). If it’s not, it checks it
(see ManglerChecker.Companion#hasMetadata).
The issue is that those two conditions are not equivalent.
When the Compose compiler plugin transforms an IR function, it copies
its `metadata` property (as it should, because `metadata` can contain
anything, not necessarily the frontend representation), but doesn't set
the descriptor. Because of that, on K1 that transformed function is
skipped in `ManglerChecker`, and on K2 it’s not.
The correct usage would be to properly distinguish which declarations
come from the FE as is, and which are transformed/synthesized,
and skip the latter. But it is unclear how to implement this.
For now, the easiest way to fix this on K2 is to not run ManglerChecker
at all.
KT-60648
^KT-59448 Fixed
Ensure that in IdSignatureBuilder hashId/hashIdAcc is only set
together with the description.
In 6142d75bb4 we implemented setting
descriptions when building signatures from descriptors, but forgot to
do the same for building signatures from IR, resulting in missing
descriptions in klibs.
See also: KT-59486
This field shall be used for storing a human-readable representation
of the declaration, that would be a mangled name for now.
This field is not yet serialized. Serialization will be implemented in
follow-up commits.
See KT-59486
Since we know that in most cases signatures for JS and NATIVE are
the same, when running a signature test for the first time, let's print
`// CHECK JS NATIVE:` instead of `// CHECK JS:` or `// CHECK NATIVE:`.
^KT-59204 Fixed
This only applies to JVM and fq-names in declaration references
in IR dumps.
This enables us to run more irText tests on platforms other than JVM
(see KT-58605).
This doesn't reduce the quality of tests, because the flags are still
printed for declarations themselves. We only omit them in references.
However, this makes the tests more compatible with non-JVM backends
(see KT-58605), because flags of referenced stdlib declarations may
differ among target platforms.
For type parameters of generic properties,
`DeclarationDescriptor#getContainingDeclaration` must return
the property descriptor instead of the accessor function descriptor.
^KT-57436 Fixed
- Mangled names of property accessors now include context receiver
types of the corresponding property when computed from FIR.
- Context receivers are now supported when computing mangled names
from IR
- IrBasedDescriptors now account for context receivers
^KT-57435 Fixed
Single-letter names were very confusing, especially in declarations like
```kotlin
private inline fun <
reified D : IrDeclaration,
reified ES : IrDelegatingSymbol<AS, D, *>,
reified AS : IrBindableSymbol<*, D>
> finalizeExpectActual(
expectSymbol: ES,
actualSymbol: IrSymbol,
noinline actualizer: (e: D, a: D) -> Unit
)
```
The reason #1 for this feature is that we want to test IdSignatures
generated for declarations. Currently, there is no (easy) way to ensure
that a change in the signature building logic doesn't cause any breaking
changes wrt klibs.
Now, most IdSignatures include hashed mangled names in them, so even if
we catch a regression where the included hash changes, there would be no
way of knowing immediately what caused it, unless we'd also have mangled
names in the expectations.
The reason #2 is to test the manglers themselves. Currently, there are
no tests for them. They heavily duplicate each other, this is already
causing issues (see KT-57427) that would be very hard to catch without
these tests.
^KT-58238 Fixed
The test is not in any way JVM-specific, but it fails on the JS BE
because of different fq-names of stdlib symbols on JVM and JS.
The fix is in progress. Mute the test until the fix is ready.
This is needed for signature tests to work with the same golden data
on both K1 and K2, since sometimes K1 and K2 produce IR with different
order of declarations and supertypes.
Only Fir2IrJvmResultsConverter respected
the IGNORE_FIR2IR_EXCEPTIONS_IF_FIR_CONTAINS_ERRORS test directive.
Fir2IrJsResultConverter didn't.
This is fixed here.
tl;dr the current design of klibs does not allow to properly deserialize
the list of sealed subclasses in a sound way. It is possible that
a subclass of a sealed class is declared in a different file, AND is
private in that file.
A more detailed explanation:
Right now we don't serialize file signatures at all.
However, a private declaration's signature must necessarily include
the file signature.
How do we serialize a private declaration's signature into a klib
and deserialize it later?
**Serialization** is simple: we just serialize the file signature as
an empty protobuf message.
When we are **deserializing** a private declaration, we look at the file
that is being deserialized right now, and construct the file signature
based on that.
This logic, however, doesn't always work. An example is KT-54028.
Basically, if we have a sealed interface with a private implementor
declared in a different file, this breaks:
1. We are deserializing the sealed interface. The deserializer knows
that we are now in the file in which the sealed interface is declared.
2. As part of deserializing the interface, we deserialize its sealed
subclasses.
3. Naturally, we come to deserializing the private implementor that is
declared in another file, but the deserializer still thinks that we are
in the file in which the interface is declared. A wrong signature is
created, which leads to linkage failure.
We *could* fix this by properly serializing the file signature,
i.e. instead of an empty protobuf message we could write the file path
and its package to the klib. However, there a problems with this
approach:
- The current design of signatures allows a situation where two
different files can have the same relative path
(for example, with the help of the `-Xklib-relative-path-base` compiler
flag) *and* the same package, which would introduce ambiguity during
linkage.
- Most importantly, this appoach won't work well with incremental
compilation of klibs. Currently we rely on the assumption that all
cross-file references are handled with public signatures, and private
signatures are only used inside a single file. This allows to move
declarations across files without recompiling it's use sites.
It has been decided to apply the following hacky solution: we just don't
deserialize the list of sealed subclasses from klibs.
The list of sealed subclasses is not used in lowerings, so it should be
safe.
#KT-54028 Fixed
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.
`@sample` is used for showing usage examples, not the generation
template.
IDEA shows the body of the method referenced in `@sample` in
the class's kdoc, which pollutes the docs with irrelevant code.
In the lowered IR there are often references to type parameters whose
containers are not in the current scope. This is incorrect semantically,
but it works in practice due to erasure, so when the mangler is used on
the lowered IR, we don't want to crash the compiler.
Otherwise, the type parameters of the `kotlin.script.state` property
of type `AggregatedReplStageState` were undefined, which led to
building an ill-formed signature for the script class constructor.
Sergej Jaskiewicz