This should solve the problem with deadlocks/performance in the K2 IDE
This is a temporary solution until the ^KT-55387 is properly fixed
^KT-55387
^KT-54890
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.
- 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
- 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
Nikolay Lunyak