Used frontend changed for K2
It turned out test was compiling only one source file (a.kt). Test adjusted, so all three source files(a.kt, b/c.kt, c/d/e.kt) are now compiled into klib, so more usecases are tested
^KT-64452 Fixed
Merge-request: KT-MR-14700
Merged-by: Vladimir Sukharev <Vladimir.Sukharev@jetbrains.com>
FirCallResolver tries to find a
candidate for the delegate's getValue and cannot parse an arrayLiteral
with a nullable coneType.Running
FirCallCompletionResultsWriterTransformer.transformArrayLiteral is
required to find the result type. Therefore, completeCall should not be
invoked with the ResolutionMode from the 'data' param, but rather in
ResolutionMode.ContextIndependent.
#KT-65022 Fixed
`tryCalculateReturnTypeOrNull` is the entry point for foreign symbols
resolution. We already have `checkCanceled` inside `lazyResolveToPhase`
and `checkIsResolved`, but in this case we will cover cases where
everything around is already resolved
^KTIJ-27504
`hasEqualFqName` is called from `hasAnnotation`, which takes more than
1% of total backend time, so it's important to avoid doing extra work
here.
It seems to be a quirk of the JS IR backend specifically that
`JsExport.Ignore` has incorrect IR parent structure here; for all other
backends, checking FQ name by traversing IR parents should work fine.
#KT-66281
`AbstractTypeChecker.isCommonDenotableType` calls a few functions which
check if the type is flexible, which is not cheap in case of JVM IR, see
`asFlexibleType`.
#KT-66281
The main purpose was to test getOrDefault w/ non/null value does not
bother the resolution. To be aligned with test file
mapGetOrDefault_nullable.kt, this one should test getOrDefault too.
All we needed was // WITH_STDLIB
It seems that K2 doesn't support `UnitConversionsOnArbitraryExpressions`
experimental language feature (KT-56011), while the test accidentally
relied on it.
Improve the test code so that it doesn't need this language feature
anymore, and enable the test for K2.
^KT-65553 Fixed
Previously, it was failing at line
(resolvedReceiver?.toReference(session) as? FirNamedReferenceWithCandidate)?.candidate?.updateSourcesOfReceivers()
But this line was mostly incorrect because in case of `a.b()` call,
which is resolved to `a.b.invoke()`, `resolvedReceiver` is pointing to
`a` instead of obviously expected `a.b`.
The fix with using `candidate.callInfo.explicitReceiver` doesn't help
either because the candidate of that receiver is always completed at
that stage (so no Candidate there).
The only case when the candidate was still there is PCLA because
in that case we explicitly don't fully complete even receiver
expressions.
(see docs/fir/pcla.md)
The idea of the fix is moving the call of `updateSourcesOfReceivers`
for invoke property receiver to the place just before the candidate
is being converted to the resolved reference
(i.e., the candidate is being lost)
^KT-66148 Fixed
In this way, only `LLFirLazyResolver` will be responsible for running
and checking the resolution result.
Also, this commit replaces redundant `checkIsResolved` for
`LLFirResolveTarget` with cheaper `checkIsResolved` for declarations.
Also, this commit adds the missing global lock for `IMPORTS` phase.
This commit doesn't change any logic for the case with disabled lock
(the default case), only updates the case with enabled lock.
^KT-66306 Fixed
Yan Zhulanow