Note that there is a questionable behavior that will be fixed later.
Right now it's not fully clear because for the same situation in Kotlin, the compiler reports warnings at declaration-site and it's not possible to do so for Java
^KT-53153
- Setup JDK default module roots in `StandaloneProjectFactory` (compare
with `KotlinCoreEnvironment`). The implementation is a distilled
version of `ClasspathRootsResolver`'s default module handling.
- This fixes an issue where some LL FIR tests with JDK 17 and 11 had
mismatched types between Kotlin and Java sources.
^KT-55566 fixed
- LL FIR tests with Java `record` classes and other new syntax features
failed because `file.packageName` in `findJvmRootsForJavaFiles`
caused the Java file to be parsed before the Java language level was
configured. The Java language level is now set up in
`registerJavaPsiFacade`, which is early enough.
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
Mikhail Glukhikh