There was a bug in the DFS. Whenever we encountered a "requires
transitive X" directive in some module, we recursively invoked DFS not
on X but on `dependencyName`, which is the target module that we're
trying to find the path to. And that always failed, because no module
requires itself.
#KT-66275 Fixed
If a potential receiver is resolved to an error type, we consider
any other type as a subtype of it and therefore may select
any candidate that we happen to find in a scope.
In particular, in the case of scripts, or code with a context receiver,
the receiver candidate resolved to a cycle was accepted as a receiver
to an invoke on a random class from stdlib.
The fix skips adding invoke resolve task in this case, allowing
the tower to find the correct candidate in another scope.
#KT-64241 fixed
#KT-65576 fixed
This check was required due to missed proper implementation for
jumping locks. Now it is safe to call `lazyResolveToPhase` under the
jumping lock – it won't lead to any deadlocks or stack overflows.
This was an implementation detail of SLC.
In the case, if we want to have proper parents for type annotations
in light classes, we have to properly implement `PsiTypeElement`
for required declarations.
^KT-66603
^KT-56870
Use JDK11 with `-Xjdk-release=6` for kotlin-stdlib.
Use JDK11 with `-Xjdk-release=7` for kotlin-stdlib-jdk7.
This allows dropping JDK6 and JDK7 from our build completely and remove
`kotlin.build.isObsoleteJdkOverrideEnabled` #KTI-1220.
#KT-57808
`isSubClassOf` was changed in an earlier commit to use the session of
`subClass` instead, but that approach comes with multiple problems:
- We need to resolve classes from the use-site to take actualization of
`expect` types into account.
- If `superClass` is a builtin and we resolve supertypes from
`subClass`'s session, we may get multiple instances of symbols for the
same builtin from different sessions (i.e. one from a stdlib session
via the use-site session and another from the fallback builtins
provider for binary libraries if `subClass` is from a binary library).
^KT-66013
- The Standalone Analysis API now correctly calculates sealed inheritors
in source modules. This causes Kapt4 to pick up on sealed subclasses
in the `modifiers` test. The change is in line with the non-FIR test
results in `modifiers.txt`.
^KT-66013
- This avoids discrepancies between Standalone and IDE mode for sealed
inheritor tests with type aliases from libraries, because in
Standalone mode, libraries are deserialized with fully expanded types,
while in IDE mode, libraries are deserialized from stubs, where type
aliases are currently not expanded.
^KT-66013
- Inheriting from a sealed class in the wrong package is illegal, so a
library test makes no sense here, as the test infrastructure wouldn't
be able to compile the library.
^KT-66013
Sergey Bogolepov