Read action is not needed because at the only call site where we try to
read the PSI element text we do it via `Document.getCharsSequence` which
does not require read action.
#KT-54971 Fixed
The file fingerprints are going to be used for
a cache invalidation in JS IR incremental cache.
It should reduce an incremental rebuild time in JS BE.
CityHash128 is used as IrFile fingerprint.
- If too few or too many type arguments were provided, they were all
thrown away in `TypeArgumentMapping`,
`FirCallCompletionResultsWriterTransformer`, and `KtFirCallResolver`.
The fix handles type arguments of the wrong arity more gracefully.
- Note for `TypeArgumentMapping`: Excess type arguments are not needed
for candidate resolution. Excess type arguments are still resolved
due to the handling in `FirCallCompletionResultsWriterTransformer`.
- Post-processing in `AllCandidatesResolver`: When all candidates are
resolved in `AllCandidatesResolver.getAllCandidates`, the function
builds a FIR file. During that resolution, the
`generic<String, String>` call (in example
`functionCallWithTooFewTypeArguments.kt`) is correctly marked as
inapplicable, but the missing type argument is inferred as an error
type. `firFile` then contains a function call
`generic<String, String, ERROR>` instead of `generic<String, String>`.
This call is still marked as inapplicable. Despite that, the
*subsequent* resolution by
`bodyResolveComponents.callResolve.collectAllCandidates` disregards
the call's inapplicability and resolves successfully into an
applicable candidate. This is because `CandidateFactory` doesn't make
any guarantees for already inapplicable calls. The fix adds
post-processing to `AllCandidatesResolver` to preserve candidate
inapplicability.
- Most tests that this commit changes had slightly different results due
to type arguments becoming resolvable.
- `wrongNumberOfTypeArguments.kt` and
`wrongNumberOfArgumentsInTypeAliasConstructor.kt`:
`ConeDiagnostic.toFirDiagnostics` prefers specific errors. Because
`ARGUMENT_TYPE_MISMATCH` is specific and `INAPPLICABLE_CANDIDATE` is
not, only the former is reported. I see no reason to pass an illegally
typed argument in either test, so the change reduces the errors to
`INAPPLICABLE_CANDIDATE`.
- `typeAliasSamAdapterConstructors2.fir.kt`: See KT-55007.
- Disable `mismatchTypeParameters` JS backend test due to its handling
of excess type arguments. See KT-55250.
^KT-54980 fixed
Optional-expectation annotations which have an actual counterpart should
have never been serialized to the kotlin_module's proto. See for example
the original (correct) implementation in the old JVM backend in
`PackageCodegenImpl.addDescriptorToOptionalAnnotationsIfNeeded`.
#KT-55611 Fixed
- LL FIR didn't report a `RECURSIVE_TYPEALIAS_EXPANSION` error on `F2`
in `recursive.fir.kt`. While the resolver correctly associates `F2`
with a cyclic error supertype in the supertype computation session,
that error supertype was never assigned to `F2`.
- Why? `F2`'s supertype is a function type, so the supertype's
`classLikeDeclaration` in `collect` is `Function1`, which has no
containing file. Thus, the `Function1` was simply skipped, without
adding `F2` to the designators to which supertypes are later applied
via `apply`.
- The fix takes supertypes without containing files into account by
crawling their type arguments, which possibly leads the collector to
further designations, such as `F2`, which is reachable via the
function type's type arguments.
^KT-55339 fixed
- LL FIR uses `ReturnTypeCalculatorWithJump` by default because it
cannot guarantee that the implicit types of non-local functions
referenced in a function `f` have been resolved during body resolve
of `f`.
- However, if `ReturnTypeCalculatorWithJump` encountered a local
function, it tried to resolve its return type even during body
resolve of that same local function. The fix delegates to
`ReturnTypeCalculatorForFullBodyResolve`, which should be used for
local declarations.
^KT-55327 fixed
^KT-55324 fixed
Newly added tests are basically copies of the existing tests on `until`.
Note that this operator is optimized for all backends, but the fact that
it's optimized is only checked for the JVM backend in bytecode text
tests.
#KT-53330 Fixed
Do not recompute children on each file request
At the same time, we should clear the roots after each compilation
just the same way as we do for common jars
Vladimir Dolzhenko