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
Since d8d8f24f62 the tests for this
diagnostic are run with the Compiler Core test infrastructure
(see `compiler/testData/diagnostics/klibSerializationTests`)
There is no need to test it separately in `FirCompilerOutputTest`.
^KT-64393 Fixed
Move handling to appropriate TestRunCheck instances to make
them separate from each other. Also this makes it possible to
use separately from the ResultHandler on specific scenarios like
in FrameworkTest.
Adds additional checks when different test filtering is used, like
ignored tests filter.
This makes SharedExecutionBuilder be able to handle tests separately
but run together in the executable.
Make test filtering matching be a check instead of the verification
code in ResultHandler. This allows turning it on/off for specific
test cases and have different checking strategies.
Return type computation of getter for synthetic property, which is
incompatible anyway (e.g. because there is no java in the hierarchy)
may cause excess dependency between return types of declarations, which
may lead to recursive problems in resolution
^KT-66313 Fixed
During this phase, the compiler will evaluate initializers of
const properties and defaults of annotation's constructor.
Evaluation results will be stored in corresponding attributes.
#KT-64151
```kotlin
// FILE: AB.kt
interface A {
val x: Int = 1
}
interface B : A {
// f/o val x: Int
// overrides: A.x
}
// FILE: C.java
public interface C extends B {
// f/o val x: Int
// overrides: (B, A.x)
}
// FILE: D.java
public interface D extends C {
// f/o val x: Int
// overrides: (C, A.x)
}
// FILE: usage.kt
fun test(d: D) {
d.x
}
```
In such test backend will ask for overriddens of lazy property C.x only
after property lowering, which removes property `B.x` and replaces it
with getter `B.<get-x>`. That fact that there is no property anymore
really confuses `SpecialFakeOverrideSymbolsResolver` during computation
of overriddens of `C.x`.
So, to prevent this situation, we can process all source kotlin classes
beforehand, so when any lazy function/property will start computation
of its overriddens, there won't be the need to calculate mapping of
f/o for classes
This problem was found during work on KT-66341, after total signature
computation removal from fir2ir. Previously those fake-overrides just
matched by signature in symbol table
FIR instances of generated toString/hashCode/equals are session dependant,
so we need some cache, which operates only session-independent stuff.
Pair of `FirClass` and `Name` was chosen here
Previously SymbolTable played the role of this cache (with signatures as
keys). But it should be replaced in scope of KT-66341 and KT-64990
Jinseong Jeon