Adding or removing a method or property with
a default implementation to an interface should
invalidate all children: we must regenerate JS code for them
^KT-56237 Fixed
The tests are removed because JvmDefault is going to be deprecated with
error in KT-54746 and removed later in KT-57696.
Many of the removed tests already had existing counterparts with the new
modes `all` and `all-compatibility`. In this change, I've added such
tests where they were missing, and removed tests which were testing
behavior specific to the JvmDefault annotation, such as some
diagnostics.
#KT-54746
In this example we get 2 variants of `kotlin/toString()`:
one coming from the KLib provider, and the
other coming from the builtins provider.
These are identical deserialized functions.
^KT-57601 Fixed
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
Zalim Bashorov