This fixes a false positive overload resolution ambiguity in FIR
when invoking a record constructor when it also defines a canonical
constructor (compact or explicit).
#KT-62151 Fixed
This fixes a false negative NO_ELSE_IN_WHEN in K2 and incidentally
also fixes a false positive NO_ELSE_IN_WHEN in K1 since the fix is in
the common code.
#KT-62491 Fixed
The fresh version of intellij has all record-related declarations,
so an additional fake constructor leads to errors like
KTIJ-25364 (OVERLOAD_RESOLUTION_AMBIGUITY)
^KTIJ-25366 Fixed
^KTIJ-25364 Fixed
^KTIJ-25368 Fixed
^KTIJ-25370 Fixed
The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
- 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.
* Change 1.6 to 1.7 constants
* Fix SAFE_CALL_WILL_CHANGE_NULLABILITY for testData
* Change EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_WARNING to EXPOSED_PROPERTY_TYPE_IN_CONSTRUCTOR_ERROR
* Change NON_EXHAUSTIVE_WHEN_STATEMENT to NO_ELSE_IN_WHEN
* Fix testData for SafeCallsAreAlwaysNullable
* Change T -> T & Any in test dumps
* Change INVALID_CHARACTERS_NATIVE_WARNING -> INVALID_CHARACTERS_NATIVE_ERROR
* TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_WARNING -> TYPECHECKER_HAS_RUN_INTO_RECURSIVE_PROBLEM_ERROR
Kirill Rakhman