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
- Direct inheritors are needed to calculate sealed inheritors. The new
`KotlinDirectInheritorsProvider` can be used to implement a common
sealed inheritors provider in LL FIR.
^KT-66013
This commit is intended to get a more clear diagnostic in case when
the type checker creates an inconsistent error type due to some
classifier inaccessibility. Before this commit, we reported simply
ARGUMENT_TYPE_MISMATCH (see test). Now we report also
MISSING_DEPENDENCY_CLASS by analyzing an error type of a qualified
expression.
#KT-66356 Fixed
Otherwise, we can get in a situation where the single item is flexible,
and we replace its attributes with the attribute of the lower bound,
which messes up `EnhancedTypeForWarningAttribute`.
#KT-65193 Fixed
Johan Bay