- `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
- `KtModuleWithFiles` isn't actually used in a production Standalone API
context, but it was exposed via `analysis-api-standalone-base`. In
current production usages, the project structure is built with the
module builder DSL.
- Hence, `KtModuleWithFiles` is only relevant for tests. This commit
moves `KtModuleWithFiles` to the Analysis API test framework and
renames it to `KtTestModule`. This removes any risk that an outside
user could start using `KtModuleWithFiles` and completely uncouples
the test project structure from production APIs.
- In addition, we can add the `TestModule` to `KtTestModule`, allowing
tests to quickly access the original test module, for example to check
the test module kind.
- The commit also removes the data class status of `KtTestModule` and
`KtTestModuleProjectStructure` to avoid issues with destructuring when
properties are added or removed.
^KT-65960
- The configuration allows the test infrastructure to decide whether to
index binary libraries to stubs (when stub-based deserialized symbol
providers are used) or to skip indexing (when class file-based
deserialization is used).
- The information is needed in `AnalysisApiBaseTestServiceRegistrar`,
where the `KotlinStaticDeclarationProviderFactory` is created. This
service registrar shouldn't access `LLFirLibrarySymbolProviderFactory`
and so checking the library symbol provider factory wasn't an option.
- Another alternative was adding a property to
`AnalysisApiTestConfigurator`. However, this then requires passing the
property to `AnalysisApiBaseTestServiceRegistrar`, because it doesn't
have access to the configurator out of the box. This however goes
against the design of our service registrars, which generally only
access test services. So adding a test service seemed like the best
solution.
^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
Usually we create synthetic property in java class if there is a property
from the base kotlin class and getter/setter with a corresponding name
in the declared scope or one of supertype scopes. But there is a case,
where the same supertype contains both property and getter:
```
// FILE: Base.kt
open class Base {
open val b = "O"
@JvmName("getBJava")
fun getB() : String = "K"
}
// FILE: Derived.java
public class Derived extends Base {}
```
In this case we shouldn't create synthetic property, because `getB()`
function is invisible for `Derived` class
^KT-66020 Fixed
- The fix uses relevant logic from `getNonLocalContainingDeclaration`.
- The annotation entry case is covered by `KtCallElement` because
`KtAnnotationEntry` is a subtype of it.
- KT-66038 is fixed by this because the static declaration provider only
indexes non-local classes.
^KT-66038 fixed
In K1, code fragment analysis was completely invalidated on any PSI
change. Because imports are not a part of the PSI tree of
'KtCodeFragment's, a colon tremble happened on 'addImportsFromString()'.
In K2, changes inside code fragments are always considered in-body
modifications. So, even with the colon trembling, the 'FirFile',
together with its 'FirImport's was not recreated.
^KT-65600 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
Generally the wrapping anonymous initializer can be used as a
"containing declaration" for some elements, but since the initialiser
for the last script expression could be dropped (the expression could
be converted to the result property), this may lead to the surprises,
e.g. as described in KT-65984
This fix marks the last initialiser as local, preventing it from being
referenced as "containing declaration".
#KT-65984
namely, add them to importing scopes directly and according to the
schema used for other implicit imports, rather than adding them
to the regular script file imports. See KT-65982 for explanation.
#KT-65982 fixed
The base class in scripting considered obsolete and therefore supported
via some ad-hoc mechanisms. In particular parameters to the base class
c-tor are passed via script provided properties. But in combination
with the resolution logic, this leads to issues described in KT-60452
This commits filters out such parameters from script resolution
scope and avoids this problem for now.
Bot it should be noted that proper diagnostics for properties shadowing
should still be implemented - see #KT-65809
#KT-60452 fixed
Here is the reasoning behind that change:
Historically, all the declarations generated by compiler plugins
were marked with `SYNTHESIZED` member kind in Kotlin Metadata
by K1 compiler.
In K1 IDE, descriptors were deserialized directly from the Kotlin
Metadata, and they saw all the generated declarations from it.
In the stubs, however, such declarations were not materialized at all.
It caused no troubles, since K1 IDE relied on descriptors to get the
essential resolution information in completion and other subsystems.
So, the resolution of members from jars processed
by compiler plugins (e.g. `kotlinx-serialization-json`) was mostly fine.
In K2 IDE, however, we use stubs to "deserialize" FIR declarations from
them, to later create `KtSymbol`s upon that FIR.
If we see a library file which was processed by compiler plugins, we
build stubs for it based on the Kotlin Metadata, and then use stubs to
create FIR.
But if stubs do not contain information about the generated
declarations,
then the resulting FIR will also not contain such declarations.
In the end, the K2 IDE would also be blind to such declarations, since
there is no other way to retrieve them from the library jar.
By meterializing all the synthethic declarations in stubs (with some
minor exceptions for data classes), we would avoid such problems,
and the resolve of such declarations from compiler jars in
K2 IDE would become possible.
Important note: currently, the Kotlin Metadata format between K1 and K2
frontends is not 100% the same; most notably, in K2, the generated
declarations are marked as regular declarations,
not as `SYNTHESIZED` ones.
Hence, if you compile a jar with the current version of K2 frontend,
then all the generated declarations would have a regular `DECLARATION`
origin, and there would be no such issues as described above.
There are two notes here:
1. K2 IDE still has to support the jars compiled by the K1 compiler,
so it still makes sense to alter the stubs and make the generated
declarations visible.
2. The issue about the different stub formats has been reported
(see KT-64924), and might be resolved in the future.
So it is possible that K2 frontend's metadata will also start
marking the generated declarations as `SYNTHESIZED`.
^KT-64808 Fixed
Before this commit, the expect-actual resolver could find expects in
regular dependencies
Note: The appeared `VIRTUAL_MEMBER_HIDDEN` in
compiler/fir/analysis-tests/testData/resolveWithStdlib/multiModule/FakeOverrides.kt
isn't caused by my change. It's caused by fixing the testData dependency
syntax notation.
The testData improperly used regular dependency syntax notation, while
it should have been using dependsOn
Before:
Regular dependency syntax notation
// MODULE: androidMain(commonMain)
After:
dependsOn dependency syntax notation
// MODULE: androidMain()()(commonMain)
The previous one was incorrect for K1 since parent of top-level function
is `IrClass`, not `IrPackageFragment`.
The change is non-functional, K1 still worked correctly, but had to do
some extra work when inlining `emptyArray` calls and produces less
performant bytecode.
Allow multiple bases with default
implementations as long as there's a
non-abstract symbol from a class.
Our rules for Kotlin are stricter than
those in Java.
Check all members for `Visibility.Unknown`,
otherwise we miss them when they come
from supertypes. This is the reason why
the FP intellij build failed with a
cryptic stacktrace instead of a
human-readable diagnostic.
Also, do report the diagnostic at all
cases of `Visibilities.Unknown`. Turns
out, there are no "simple to reason
about" situations here :(
Also, an interesting detail:
`retrieveDirectOverriddenOf` returns an
empty list for intersection overrides.
But this doesn't seem to break anything...
Replacing `CANNOT_INFER_VISIBILITY`'s
type `KtDeclaration` with
`PsiNameIdentifierOwner` and the related
changes in `PositioningStrategies`
were needed to prevent an exception saying that
`PsiClassImpl` is not a subtype of
`KtDeclaration`.
This code does lead to inferring
`Visibilities.Unknown`, but it's not
reported anywhere. This is because it
happens inside `AbstractIntSet` which
comes to us "pre-compiled" by javac,
whereas `FirOverrideChecker` only checks
members within `KotlinClass`.
^KT-65972
Marco Pennekamp