`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
- 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
- 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
This `klibSourceFile` information is deserialized from klibs
to retain the information of the original SourceFile location
of a declaration.
^KT-66271 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
This is the first implementation of a control flow graph facade for the
extract function IDE refactoring. The exact contents of
'KtDataFlowExitPointSnapshot' will be refined later.
^KT-65762 Fixed
Foreign values (such as '_DebugLabel' properties contributed by the
debugger) don't have a parent (or a valid source element in general).
^KTIJ-27382 Fixed
Strictly speaking, callable references are not calls. However, type
arguments are still inferred for references, and 'KtCall' is the only
place in Analysis API that exposes call-substituted types.
^KT-66485 Fixed
This previously worked on accident because the get call in an
augmented array assignment wouldn't have a resolved argument list, and
so `argumentsToSubstitutedValueParameters` would return null.
Now, we additionally verify that we're in a `set` call.
#KT-66124
They are mostly necessary for argument mapping during resolution.
To support a couple checkers, we transform named args for varargs
into "fake" spread expressions.
Other than that, named arguments aren't needed for anything and often
lead to bugs where we forget to unwrap them for something, so it's
better to get rid of them.
#KT-66124
It's not really necessary if the information about if the lambda was a
trailing lambda can be directly saved in FirAnonymousFunctionExpression.
Removing the FIR node uncovered a couple of bugs
(UNINITIALIZED_ENUM_ENTRY, ERROR_IN_CONTRACT_DESCRIPTION) that were
caused by assuming that a lambda is always a trailing lambda.
#KT-66124
Originally it was an application-level component, which caused non-trivial
logic and cognitive load to carefully handle those extensions to avoid
memory leaks.
6740a596 introduced a way to easily register `DiagnosticSuppressor` to
project, and this commit continues this work, making it a proper
project-level extension
A lot of changes caused by the fact, that this extension is needed to be
obtained from `BindingContext` (see `BindingContextSuppressCache` and
its usages), so almost all changes are introducing `Project` to
`BindingContext`
^KT-66449 Fixed
This extension point allows changing the return type of call
from a declared type to its subtype.
With an idea that such a plugin needs the ability to
control available (extension) properties for this type.
A set of properties should be decided based on the resolved function,
provided arguments, types, and resolved lambdas.
It is not a goal to enable plugins to affect resolution in any way.
Types are not intended to have any structured capabilities
In other words.
The goal was to come up with a way to enable a limited form
of an "extensible records" mechanism through plugins.
- It should give enough value for a practical use.
(more info in the ticket).
- It should have minimal effect on the compilation process
This appears to be an extension point that solves this problem.
^KT-65859 Fixed
When we have parameters of annotation like
```
// FILE: Anno.kt
package p3
@Target(AnnotationTarget.FUNCTION)
annotation class Anno(vararg val x: String)
// FILE: main.kt
import p3.Anno
@Anno("A", "B")
fun foo(): Int = 10
```
the K2 CodeGen causes an exception reporting the unresolved type
reference. A lazy resolution call fixes the issue.
In addition, FIR for the value parameter to IR conversion fails because
`Fir2IrLazyProperty` for the value parameter tries to resolve the
initializer before creating the `IrParameterSymbol`. When it checks the
`localStorage`, it reports an error for the missing `IrParameterSymbol`.
This commit adds `IrParameterSymbol` before resolving the initializer.
^KT-65099 Fixed
If actual declaration is broken (missing explicit `actual` keyword),
expect declaration still makes sense.
This way, we allow refactorings on broken code
^KT-65191 fixed
- The module structure for these tests was set up backwards: We should
keep the test module kind of the main module flexible (as it is
configured by test configurators), but keep the module kinds of the
binary libraries fixed.
^KT-65960
^KT-64994
- `LibraryBinary` should not contain any decompiled files, as we want
FIR symbols in tests to be provided from indexed stubs or class files,
but definitely not from decompiled PSI. This brings `LibraryBinary`
much closer to the behavior of binary libraries in the IDE.
- Some tests may still require access to a decompiled file, for example
when trying to test `getOrBuildFir` for some `KtElement` coming from a
library. This commit introduces `LibraryBinaryDecompiled`, which
does contain decompiled files.
- We don't really need `LibraryBinary` as a main test module kind
anymore, since tests generally want to access some main `KtFile`.
Hence, test configurators for `LibraryBinary` have been turned into
configurators for `LibraryBinaryDecompiled`.
- An alternative would be decompiling files on demand, but this is not
currently feasible because the Standalone API doesn't reconcile stubs
with decompiled PSI, like the IDE does automatically. (For the same
declaration, the stub and the PSI will have a different identity.) As
long as there is no support for this, we'll have to rely on a separate
test module kind.
^KT-65960
- `TestModule.explicitTestModuleKind` requires a directive to be present
to get the `TestModuleKind`. But we still want to find out the test
module kind for test modules without a directive. Hence, we have to
add this property to `KtTestModule` during its construction.
^KT-65960
When a symbol X from a binary library A uses another symbol Y from
another binary library B, `LLFirDependenciesSymbolProvider` cannot
resolve Y for X. This is because the existing
LLFirAbstractSessionFactory passes symbol providers for only builtin
libraries to `LLFirDependenciesSymbolProvider` even when the session has
dependencies. As a result, when `LLFirDependenciesSymbolProvider`
searches a symbol, it can find only symbols from the builtin libraries,
but it cannot find a symbol from libraries other than builtin libraries.
This happens only for the binary libraries.
^KT-65240 Fixed
This commit adds code to check whether a deserialized cone type is a
special function type kind or not when resolving the type of a lambda
expression (anonymous function). If it is a special function kind, it
sets the type of lambda based on the special function kind.
^KT-64994 Fixed
The test infrastructure for analysis supports binary module tests, but
the binary build does not use another binary module as a dependency when
it passes the class path. As a result, each binary module build does not
work when they have dependency on each other.
This commit fixes the issue by
1. Topological sort in the order of dependency graph for test modules.
2. Pass module paths as extra class paths when they have dependency on
each other.
^KT-64994