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.
There were still some cases where the generated function reference class
would contain references to generic parameters that were not in scope.
One example of that was `Array<*>::get`. Before this fix the generated
function reference class would still contain a reference to the
type parameter declared in the `Array` class.
Also, the logic of generifying the generated function reference class
was incorrect. For example, for function `fun <A, B> foo()` if we had
a reference `::foo<T, T>` (where `T` comes from the outer scope),
the class would still contain two generic parameter, despite that only
one generic parameter from the outer scope was referenced.
This is also fixed here.
4a2a77d9b9 introduced a regression
where for bound references to functions generic over their receiver
the generated class was also generic even if the function reference
itself only contained concrete types. This is fixed here.
Previously, a function reference that used generic parameters from its
outer scope was lowered into a top-level non-generic subclass of
`FunctionN`, with `FunctionN` type arguments referencing type parameters
not present in the scope anymore. This sometimes resulted in generating
malformed mangled names.
From now on the generated subclass of `FunctionN` is generic. The needed
type arguments are passed upon instantiation, when the relevant generic
parameters are present in the scope.
1539d7ef1a brought some package names in
sync with the directory layout. However, this broke some third-party
code that used classes from those packages.
The new compatibility aliases allow that code to continue to compile.
Deprecation warnings will be emitted, suggesting to replace the imported
packages with new ones.
Basically, some package names were Native-specific, whilst the packages
themselves were not Native-specific at all. This was already reflected
in the directory layout, but not in the package names.
This is fixed here.
NFC, just an automatic rename of packages with fixes of imports.
Refactor the renderer, make BoundSymbolReferenceRenderer a static class
to prevent calling RenderIrElementVisitor's methods from it to avoid
infinite recursion in the future.
^KT-52677 Fixed
- Generate mappings for function parameters
- Don't generate debug info for dots in qualified references
- A location of a JsNameRef is considered the start of the rightmost
name
We will need it to generate original names for catch parameters in
sourcemaps.
Also, don't generate redundant debug info for compiler-generated
exception handling control flow operators.
See the doc comment to the MultipleCatchesLowering class
#KT-46276
- Map generated explicit Unit returns to the closing brace of
the original body
- Name the continuation parameter as `$completion` to match the JVM BE,
and generate debug info for it (so that it appears in the 'names'
array in sourcemaps)
- Don't generate debug info for coroutine instantiation ceremony
(so that the user doesn't need to step in many times to get where they
want)
#KT-46276
The `getSourceForArgument` method should be in the interface,
but adding it is a breaking change for Java usages,
since the module is not built with -Xjvm-default (KT-54749).
Move the method to an extension. This doesn't change the behavior,
since it was only ever called on LazyAnnotationDescriptor.
Namely:
- Generate debug info for closing braces, which allows the breakpoints
set on closing braces to be hit
- Generate debug info for 'if' and 'try/catch' statements.
KT-46276
It is possible that the source info has the type `KtPureElement`.
For example, the serialization plugin may create a synthetic companion
object for a `@Serializable`-annotated class.
This results in an instance of
the `SyntheticClassOrObjectDescriptor.SyntheticDeclaration` class being
indirectly set as source info. This class implements the `KtPureElement`
interface.
We already have stepping tests for Kotlin/JVM.
They are helpful for testing the correctness of the generated
debugging information.
They are better than line number tests in that they allow to test the
_behavior_, not the generated data. The structure of the data may change
even if the behavior stays the same. For that reason, stepping tests
are more stable.
We can now write expectations in the following form:
// EXPECTATIONS [backends...] [frontends...]
Backends are specified as in the TargetBackend enum.
Frontends are specified as in the FrontendKinds object.
This will make it more suitable for supporting Kotlin/JS in stepping
tests.
For example, for expectations that match only JVM backends with the
classic frontend, we use:
// EXPECTATIONS JVM JVM_IR ClassicFrontend
Sergej Jaskiewicz