Use test compiler runner to compile JS libraries. Determine compiler
by the specified TARGET_PLATFORM. Add tests for dynamic type and
JS-specific .proto extensions.
Refactor the code for mock library compilation to make the switch
between platforms more straightforward.
KTIJ-27566
KT-63217
Note on .kjsm library symbol providers.
It's not clear whether the provider is necessary for K2 IDE and whether
there will be libraries with .kjsm files that we are going to support.
Since there are no tests that can prove the correct work of the symbol
provider right now, it's better add them later if needed.
The existing tests cover only .knm files.
KTIJ-27566
- Old backend support is not needed in `KtFe10CompilerFacility` anymore,
because it has been removed for the bytecode tool window, which was
the only user. The old backend is slated to be removed entirely.
^KTIJ-24522
We can omit `get` call to delegated property and inline
constant value directly. If we are not going to
do that, we can get a runtime exception because
all usages of const property will be inlined and the property
itself will be dropped.
#KT-63567 Fixed
#KT-63580 Fixed
When fixing KT-22004, the analysis was incomplete, the details are
available at KT-63540. This change restricts the ignore of conflicting
overloads on hidden callables only for final ones.
^KT-63540 Fixed
Previously, because we didn't handle flexible types properly in
prepareCapturedType, projections inside flexible types would only be
captured during subtyping with captureStatus=FOR_SUBTYPING
which would lead to the constraint type being wrongly approximated
(see ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint).
Fixing the capturing produced two kinds of false positive diagnostics:
1. In ConstraintInjector.TypeCheckerStateForConstraintInjector
.addNewIncorporatedConstraint we would get two instances of cone types
that are structurally equal and containing the same captured type.
However, because we only skipped subtyping if the types were
referentially equal, we would get a contradiction here.
The fix was to use structural equality instead, which should be okay
as the captured type instances are the same.
2. Reified type variables were inferred to captured types because
flexible arrays with captured upper bounds
(Array<Foo>..Array<Captured(out Foo)>?) were not properly approximated.
#KT-62609 Fixed
We should pass container for correct logic around CLASS_HEADER_ANNOTATIONS.
Also, such correct containers will be used in the context of KT-63042 to
correctly detect an annotation ownership
^KT-63042
^KT-63842 Fixed
There are still some places in `.fir.kt` where false-positive reports
remained. This is because of IR checker, which will be fixed in next
commit.
^KT-31636
After previous commits IrActualizer runs only there are at least two modules
in backend input. So to check diagnostics from Actualizer all tests
should contain at least two modules
Diagnostics in test `extendExpectedClassWithAbstractMember.kt` were
changed because there is an exception from IrActualizer caused by
errors from frontend (`ABSTRACT_METHOD_NOT_IMPLEMENTED`), which is
swallowed by this kind of tests
Fir2Ir conversion consists of multiple steps with complex logic (like
conversion of each module, actualization, plugins application, constant
evaluation), and to ensure that they all are executed correctly it's
convenient to have the single entry point for all this machinery
This fixes processing of annotations on enum entries.
Before, the check in BodyResolveContext.forAnnotation would set the
tower data mode to CLASS_HEADER_ANNOTATIONS because no containers were
present.
This would lead to some tower data elements like nested classifiers
missing, which would lead to false positive unresolved references.
#KT-63761 Fixed
This commit does two things:
- prioritize type parameter scopes against static scopes in body resolve
(effectively it's a revert of KT-58028 fix)
- consider type parameters as inapplicable callable, so during callable
resolve we can go up the tower and still resolve to static scope
This allows both KT-58028 and KT-63377 to work properly
#KT-63377 Fixed
FirDefaultArgumentsInExpectActualizedByFakeOverrideChecker is an adhoc
checker which can be converted to ExpectActualCheckingCompatibility to
reuse common expect-actual checking infrastructure.
^KT-62913 Fixed
Review: https://jetbrains.team/p/kt/reviews/13094/timeline
Tests that were broken by one of my previous commits are now fixed:
- actualFakeOverride_paramsAreCompatibleViaSharedMethodWithDefaultParams.kt
- inheritedJavaMembers.kt
DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE diagnostic
disappeared in delegation.fir.kt because only one
AbstractExpectActualChecker incompatibility can be reported at a time
(DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE is now reported
not by adhoc checker but by common AbstractExpectActualChecker). It
would be nice to report both of them, but it's a separate issue KT-62631
delegation2 test makes sure that
DEFAULT_ARGUMENTS_IN_EXPECT_ACTUALIZED_BY_FAKE_OVERRIDE is reported when
NO_ACTUAL_CLASS_MEMBER_FOR_EXPECTED_CLASS is fixed
^KT-63550 Fixed
Review: https://jetbrains.team/p/kt/reviews/13094/timeline
Now it's required to create a new ScopeSession when searching for expect
members for actuals. If you keep reusing actualScopeSession then members
declared in platform may "slip into" the search results, resulting an
incorrect expect for actual (e.g. it happens in
supertypeIsExpectActual_covariantOverrideOfInjectedFromSuper_transitiveSubstitutionFakeOverride.fir.kt)
I suppose that it always has been a bug that we reused
actualScopeSession because we were mixing actualScopeSession and
expect FirSession (which is a bad idea), but we simply didn't have cases
where this bug could be observed. Now after we started matching
fake-overrides, we have such cases.
But creating a new ScopeSession every time is a suboptimal solution. We
need to design a scope caching KT-63773
Nikita Nazarov