Warning Context:
> Task :js:js.tests:generate-ts-for-regular-classes-in-exported-file
Execution optimizations have been disabled for task ':js:js.tests:generate-ts-for-regular-classes-in-exported-file' to ensure correctness due to the following reasons:
- Gradle detected a problem with the following location: './js/js.translator/testData/typescript-export/regular-classes-in-exported-file'. Reason: Task ':js:js.tests:generate-ts-for-regular-classes-in-exported-file' uses this output of task ':js:js.tests:generate-js-export-on-file-for-regular-classes' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.
> generateTypeScriptTests
> tsc --build ./typescript-export/regular-classes-in-exported-file/tsconfig.json
This fixes a FIR-specific issue where a type variable is inferred to
Any instead of dynamic. K1 wasn't affected because of a FIR-specific
condition in ResultTypeResolver.
#KT-57962 Fixed
The changes to the irText test data result in the fact that we
now unconditionally unwrap substitution overrides of delegation targets
whereas before we built an unsubstituted scope of the type we delegate
to. If we delegate to a class A : B<C>, the unsubstituted scope of
A can still contain substitution overrides for inherited generic methods
from B<T> that we didn't unwrap before but do unwrap now.
#KT-57899 Fixed
For CallKind.VariableAccess, the condition when to *skip* resolution of
objects was previously collector.isSuccess. This wasn't strict enough
because collector.isSuccess could be true when the best found candidate
has an applicability like RESOLVED_WITH_LOW_PRIORITY (e.g. from dynamic
scope or annotated with @LowPriorityInOverloadResolution). In these
cases, we do want to resolve objects. To fix this, the condition is
changed to collector.shouldStopResolve which is stricter.
#KT-57960 Fixed
Current qualified access resolving algo rely (likely incorrectly,
see #KT-58037) on a providers' "knowledge" about parent packages.
This commit adds this "knowledge" to k-lib based provider.
#KT-57353 fixed
The patch adopts and reuses the optimizations from the legacy backend.
The optimizations remove useless temporary variables,
statements and simplify generated JS code.
The optimizations can be disabled by `-Xoptimize-generated-js=false`.
Related to KT-51139
Enabled Partial Linkage may replace entire IR expressions with a stub
during klib linking and loading. This may break the incremental cache
dependency graph. Dropping incremental cache files after updating klibs
(e.g. update klib version) covers almost all cases which
could not be tracked due to a broken dependency graph.
This patch could be reverted after fixing KT-57347
Add a special annotation @JsExternalTypeArgument for
marking function parameters. The marked parameter
accepts an argument with an external type only.
^KT-57479 Fixed
This fixes a scenario when INVISIBLE_REFERENCE is suppressed, but we
resolved to the wrong overload because when none of the candidates were
applicable, more or less the first one was chosen.
Because we call `fullyProcessCandidate` on the candidates, their
applicability can change which can lead to a situation where the
applicability of a ConeAmbiguityError is different to all its
candidates. The changes in coneDiagnosticToFirDiagnostic.kt account for
that, otherwise code like candidates.first { it.applicability ==
CandidateApplicability.UNSAFE_CALL } can throw NoSuchElementException.
#KT-57776 Fixed
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
Ivan Kochurkin