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
`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
- 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 `klibSourceFile` information is deserialized from klibs
to retain the information of the original SourceFile location
of a declaration.
^KT-66271 Fixed
It's caused by checking the return type of an inherited property.
toConeKotlinTypeProbablyFlexible() returns an error type when the
type ref is unresolved instead of throwing.
This "breaks" some override checks and in the added test, it leads
to an additional candidate being created for a synthetic property.
However, the candidate has applicability K2_SYNTHETIC_RESOLVED
and gets filtered out because the real property has a higher
applicability.
#KT-66392 Fixed
`StubBasedFirTypeDeserializer` handles function parameter with a
receiver with a special exception, which sets it as
`ExtensionFunctionType`, but skips setting special function kinds for it
even when the function parameter type is a special function kind. This
drops `Composable` annotation from a lambda expression if the function
parameter taking the lambda expression as an argument has a receiver,
which causes a severe CodeGen error for Compose app on K2 Android
Studio.
^KT-66526 Fixed
In fact the latest compiler (neither K1 nor K2) does NOT report an error
here, see KT-66522. The error was there in the diagnostic test because
the test used custom code which invoked parts of the old JVM backend to
report signature clash errors.
The issue is rather minor and is present since 1.5, so to reduce
confusion, the test is deleted.
#KT-66522
In this commit, tests where backend diagnostics were reported correctly
are being moved.
FirScopeDumpHandler was added to FIR diagnostic tests with JVM backend
to support `SCOPE_DUMP` in `overridesBuiltinNoMagic.kt` and
`charAtAndOverload.kt`.
Ilya Chernikov