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
A type alias may still be inherited from. For example:
```
sealed class MyClass
typealias T = MyClass
class Inheritor : T() // `Inheritor` is a direct inheritor of `MyClass`.
```
The index is a simplified version of the IDE's
`KotlinTypeAliasByExpansionShortNameIndex`, but it should be sufficient
for virtually all cases.
^KT-66013
- The new `LLSealedInheritorsProvider` is based on the previous
sealed inheritors provider implementation in the IDE. It uses the
new direct inheritors provider and the module dependents provider to
implement the same functionality that was previously confined to the
IDE. With this design we avoid duplication of complex logic such as
the KMP handling in `searchInheritors`.
- The implementation is designed to work in the production Standalone
mode and the aforementioned services have already been implemented for
Standalone in prior commits. Now we can get rid of the problematic
`SealedClassInheritorsProviderForTests` and tests should more closely
match production behavior.
- In IDE mode tests, `LLSealedInheritorsProvider` is used with
Standalone Analysis API provider implementations. This is in line with
the rest of the test infrastructure, where Standalone AA providers are
generally used, as IDE providers aren't available.
- `KotlinSealedInheritorsProvider` is made obsolete by the common sealed
inheritors provider.
^KT-66013 fixed
^KT-64505 fixed
- We are relying on static indexing to find candidates for sealed
inheritors, hence the extension to the index.
- The direct usage of `KotlinStaticDeclarationProviderFactory` in
`KotlinStandaloneDirectInheritorsProvider` is not pretty, but a proper
design requires making the static index available as a service and
moving "static" services to the Standalone API (from AA providers).
^KT-66013
- When calculating sealed inheritors for expect classes, we need to
expand the search scope to modules with a depends-on/refinement
dependency on the module containing the expect class, as these modules
may contain additional sealed inheritors. `getRefinementDependents`
allows us to get these refinement dependents to build the proper
search scope.
^KT-66013
Alexander Udalov