The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
Enum entries can be used as types in Kotlin (even it's a compilation error)
To use the classifier as a type, we need to find if it's hidden or not.
The deprecations for classes are calculated on COMPILER_REQUIRED_ANNOTATION phase, and that's okay as it goes before the TYPES phase.
For enum entries, the deprecations are calculated on TYPES phase which goes on TYPES phase.
This is incorrect as we cannot jump from lower phase to upper phase
The hack ignores such deprecation search for enum entires.
Test: org.jetbrains.kotlin.analysis.low.level.api.fir.diagnostic.compiler.based.LLFirPreresolvedReversedDiagnosticCompilerFE10TestDataTestGenerated.Tests.testEnumEntryAsType
^KT-57648
^KT-56543
Since we forbid overriding `equals` for
value classes, and value classes may only
implement interfaces, we know everything
about their `equals`, hence we can
guarantee if it always returns `false`
for different value classes.
The problem appeared because not all of the `realOverridden` have been
collected because inside AbstractSerializableListDecorator some of the
scopes returned the same instance as direct overridden and after that
overridden tree traversal stopped without detecting real overrides.
Thus, the modality of intersection for
AbstractSerializableListDecorator::size and MutableSet::size
was incorrectly computed to ABSTRACT
The similar thing is already done at the place where we're obtaining
all overrides.
See https://github.com/JetBrains/kotlin/commit/c80cfb0fdb00323ba9b5e1dd98c5cbd0bfab6b8b#diff-182d90c9b8050557e4e2eb319a84b9a51fd0600c728dd0fce85cf6491c13e16dR152
^KT-57693 Fixed
Meta issue: KT-8575
^KT-58061 Fixed
Review: https://jetbrains.team/p/kt/reviews/9677
This commit fixes an inconsistency between
FirUnsupportedSyntheticCallableReferenceChecker and
UnsupportedSyntheticCallableReferenceChecker
In K1 such properties were not considered synthetic and are called
JavaPropertyDescriptor. That's why we need to do an additional check in
K2 checker, while in K1 we didn't need to do it
Also see the previous commit for more related tests that already was
green without this fix but are related to KT-58061 problem
Review: https://jetbrains.team/p/kt/reviews/9677
I'm going to fix KT-58061 in the next commit. Firstly, let's cover
FirUnsupportedSyntheticCallableReferenceChecker with more tests that
already pass, but are related to KT-58061 problem.
Other related tests:
- testGenericJavaProperty
- testFunInterfaceConstructorReference
Meta issue: KT-8575
Review: https://jetbrains.team/p/kt/reviews/9595
UnsupportedSyntheticCallableReferenceChecker only existed for K1,
because we wanted to release the feature for 1.9 and the feature should
have been working for K2 unconditionally. But since, we're postponing
the release until 2.1, we also need to port the checker from K1 to K2
The issue is that during binding fake overrides, the compiler doesn't
differ setters from its properties, so the compiler uses the same
visibility for setter and entire property.
Changing logic at the binding stage can cause some unpredictable consequences so
the fix is to do this differentiation right at the reporting stage
^KT-56662 Fixed
Merge-request: KT-MR-9565
Merged-by: Michail Zarečenskij <Mikhail.Zarechenskiy@jetbrains.com>
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
It was working incorrectly, because we've been trying to fix
P1 variable to intersectTypes(String?, StubForP2) that should result
to String? because we've got stubEqualsToAnything enabled there,
but nullability was being chosen incorrectly because
`StubForP2.isNullableType()` returned false
NB: The code inside `is ConeTypeVariable` case wasn't working properly
because it always `lookupTag.toSymbol(session)` always returned null,
thus there was effectively five dead lines of code there.
^KT-57814 Fixed
^KT-57921 Related
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
The change in `FirDiagnosticsHandler` ensures
`DEBUG_INFO_DYNAMIC` is still reported in
`FirPsiJsOldFrontendDiagnosticsTestGenerated.testConventions`.
Support `SPREAD_OPERATOR_IN_DYNAMIC_CALL` and
`WRONG_OPERATION_WITH_DYNAMIC`
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
In K1 .isFun is always false for Java classes, so extra check
is added for that. This is not needed for K2, because .isFun is
true for all Java classes. Here it is not necessary to check
that interface has only one method, because such check will be
done in the place where interface implementation is created.
^KT-39362 Fixed
Dmitrii Gridin