The constructor with the required parameters may
not have been defined, and since JS/IR box tests
pass, it seems, we don't have to resolve
into anything meaningful. We could generate
the appropriate constructor like dynamic type
members are generated, but, again, K1 IR doesn't
even contain a delegating constructor call.
^KT-57809 Fixed
* Fix performance of ArrayList.addAll methods in JS stdlib: extend the backing array and copy elements manually
* Update expected reachable nodes after DCE in test data
---------
Co-authored-by: Ilya Gorbunov <ilya.gorbunov@jetbrains.com>
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
Add a special annotation @JsExternalInheritorsOnly for marking
external interfaces and classes. The marked interface or class
can’t be a parent for non external interfaces, classes or objects.
^KT-57423 Fixed
If dispatch receiver is dynamic and call on it is not dynamic that means
that this call was resolved to some specific declaration because of
smartcast. So we should use original type of this declaration as
dispatch receiver during calculation of IdSignature instead of Any
(which came from dynamic type). Otherwise we will have two different
signatures for the same member declaration
^KT-57682 Fixed
This parameter accepts the name of the "mode" in which the partial linkage would work. Currently, only two options are supported: 'enable', 'disable'. But the list may be extended in the future as needed.
At the moment the 'disable' option is the default one. This will be changed in #KT-51447, #KT-51443.
Avoid using source+KLIB+cache?->binary compilations in KLIB ABI tests. Such compilations are not supported by Native K2 and thus will block migrating ABI tests to K2.
Overriding equals, hashCode, toString and any other member that is not
expect does not require satisfying the rules of expect-actual matching.
#KT-57381 Fixed
1. Leaving no unbound symbols in the IR tree, KT-54491:
- All unbound symbols are bound to synthetic stub declarations
- Improved detection of the root cause for every partially linked classifier
- Improved error messages
2. Visibility valiation, KT-54469
3. Always check deserialized symbols:
If the deserialized symbol mismatches the symbol kind at the call site in the deserializer then generate and reference another symbol with the same signature. In case PL is off, just throw IrSymbolTypeMismatchException.
4. Handle class inheritance violation:
- Detect illegal inheritance (ex: inheriting from a final class)
- Detect invalid constructor delegation (ex: delegating to another class than the direct superclass)
- Simplification: Reduce the number of PartialLinkageCase subclasses
- Reworked error message generation to have shorter and clearer messages
5. Handle class transformations and all known side-effects, examples:
- nested <-> inner
- class <-> enum/object
- adding/removing subclasses of sealed class
- adding/removing enum entries
6. Check direct instantiation of abstract class.
Such instantiation could be possible if a class was non-abstract in the previous version of a library.
7. Handle unlinked annotations on declarations.
Such annotations are removed from the IR. The appropriate compiler error message is produced for every individual case.
8. Handle value argument count mismatch at call sites
9. Handle calling suspend function from non-suspend context.
This could happen if a suspen function was non-suspend in the previous version of a library.
10. Handle overriding inline callables.
Only the leaf final callable can be marked with `inline`.
11. Detect illegal non-local returns from noinline/crossinline lambdas.
Nikolay Lunyak