- An LL FIR test failed after merging stub-based deserialized symbol
providers into combined Kotlin symbol providers:
`DiagnosticCompilerTestFE10TestdataTestGenerated.TestsWithStdLib.Multiplatform.testJvmOverloads`
- Cause: The combined Kotlin symbol provider was able to find a class
for `JvmOverloads`. However, the `KtModule` of `JvmOverloads` was
`LibraryByRoots` with just the stdlib, while the registered stub-based
deserialized symbol provider was known to the combined symbol provider
with a `LibraryByRoots` containing 6 different paths. Hence, the
single-root module wasn't found in the provider map.
- The fix creates a `LibraryByRoot` for each root, which leads to a
separate deserialized symbol provider for each of the six roots,
solving the discoverability problem.
- In LL FIR, we have increasingly formalized symbol name caches as
palpable objects. The main reasons for this formalization were the
need to share implementations of caching between different (LL FIR)
symbol providers, the need to build composite name caches from
individual name caches, and the introduction of resolve extensions
which may provide additional declarations and thus complicate the name
set construction for Kotlin symbol providers in LL FIR.
- `LLFirSymbolProviderNameCache` also shared a lot of similarities with
cache handling in FIR providers like
`FirCachingCompositeSymbolProvider` and
`AbstractFirDeserializedSymbolProvider`.
- This commit introduces a `FirSymbolNamesProvider` as a component of
`FirSymbolProvider`. This symbol names provider's task is to provide
the sets of names which `FirSymbolProvider` previously provided. It
also allows sharing implementations of `mayHaveTopLevel*` once and for
all, which is an improvement over the previously scattered
implementations (the same ideas replicated many times throughout
different symbol providers).
- `FirSymbolNamesProvider` by design doesn't cache, as many symbol
providers may not need such a cache. `FirCachedSymbolNamesProvider`
can be used to cache symbol names if needed. The symbol name provider
architecture also makes it easier to switch between caching and
non-caching, without the need to reimplement caches every time.
- Synthetic function types complicate the picture, but this complication
is now exposed with the rest of the API, instead of being hidden in a
few implementations here and there. This allows symbol providers to
more explicitly state whether they can provide generated function
types, which is an advantage for the correctness of composite symbol
providers.
Some specific notes:
- In `FirSyntheticFunctionInterfaceProviderBase`, the class ID check has
been replaced with a full `mayHaveTopLevelClassifier` check so that
the cache doesn't get filled with `null` entries.
- `LLFirKotlinSymbolProviderNameCache` is turned into a non-caching
`LLFirKotlinSymbolNamesProvider` so that this symbol names provider
and those of resolve extensions can be composed into one caching
symbol provider in `LLFirProviderHelper` without creating layers of
caches. If the Kotlin symbol names provider was caching out of the
box, `LLFirProviderHelper.symbolNameCache` would cache the
names (1) in the combined symbol names cache and (2) in the Kotlin
symbol names cache.
- A caching Kotlin symbol names cache can still be created easily with
the `LLFirKotlinSymbolNamesProvider.cached` constructor function.
- This enables merging `JvmStubBasedFirDeserializedSymbolProvider`
into `LLFirCombinedKotlinSymbolProvider` automatically.
- Crucially, we have to also allow callable caches to take already found
callables as a context.
- We can also simplify the name cache boilerplate using
`LLFirKotlinSymbolProviderWithNameCache`.
- `LLFirKotlinSymbolProvider` is a shared interface for any symbol
providers that are based on `KotlinDeclarationProvider`.
- `LLFirKotlinSymbolProviderWithNameCache` simplifies symbol provider
implementations which use a `LLFirSymbolProviderNameCache`.
- Note that the domain is not limited to "Kotlin symbol providers",
but I don't want to introduce a general base class like
`LLFirSymbolProviderWithNameCache` without multiple class
inheritance (think Scala traits).
- It would be possible to use delegation instead of such a base class,
but that would require a shared interface for the "package name"
functions, which would require some compiler refactoring as well.
- We can base `LLFirProvider$SymbolProvider` on
`LLFirKotlinSymbolProvider`.
- The callables functions in `LLFirKotlinSymbolProvider` expect
`KtCallableDeclaration`s instead of `KtFile`s. This is the preferred
interface, because callable files are only needed for `LLFirProvider`,
not Kotlin symbol providers in general (such as the stub-based
deserialized symbol provider). This also has the advantage that FIR
files containing only properties won't be built for
`getTopLevelFunctionSymbolsTo` and vice versa.
- `KotlinDeclarationProvider` supports computing the top-level callable
package name set now, so we can propagate it to the symbol name cache
implementation.
- Adds the package name check to `getTopLevelCallableNamesInPackage`
directly, which will likely reduce the size of
`topLevelCallableNamesByPackage`, because it needs to store fewer
empty sets.
Nested classes which are not inner class should not be able to access
type parameters of the outer class. Make sure access is not available
when resolving super types.
#KT-54748 Fixed
Cases when default argument inhertied from super class are allowed.
Some tests for default arguments already exist and can be found in
`testData/diagnostics/tests/multiplatform/defaultArguments`, for example
`annotationsViaActualTypeAlias.kt`.
^KT-57614 Fixed
Merge-request: KT-MR-10356
Merged-by: Roman Efremov <Roman.Efremov@jetbrains.com>
When we create `SmartTypePointer` directly inside `JavaSymbolProvider`,
the Java resolution is called which is forbidden inside the
`JavaSymbolProvider`.
Instead, the lazy `JavaElementTypeSource` for JavaType is created,
which creates a `SmartTypePointer` outside `JavaSymbolProvider`.
^KT-58194
This is needed to allow using PSI pointers in IDE in JavaElement.
`JavaElement`s are reused between read actions,
so underlying PSI elements might be invalidated when using hard PSI references
^KT-58194
then, for compiled code deserialized fir would be used instead of building
decompiled text and consequence building and resolving of raw fir;
type for ktTypeReference from compiled code is called e.g., by UAST inspections
when they check annotations of the called function parameters
This doesn't reduce the quality of tests, because the flags are still
printed for declarations themselves. We only omit them in references.
However, this makes the tests more compatible with non-JVM backends
(see KT-58605), because flags of referenced stdlib declarations may
differ among target platforms.
When an annotation constructor value parameter is annotated with the
very same annotation, FIR2IR went in an infinite loop when trying
to generate it.
To fix this, the constructor is added to the Fir2IrDeclarationStorage
cache before generating the value parameters.
To accommodate for the missing parameters, the value arguments count
is determined using the FIR.
"oldJvm*" tests are no longer testing the old JVM backend, so remove
that prefix from them. Also, remove the test "firAgainstOldJvm" because
it is now checking something that cannot NOT work.
The feature was previously enabled unconditionally in K2 which
triggered a bug when an enum has an entry with the same name as itself.
#KT-58897 Fixed
#KT-52774
JvmMappedScope.Signatures became mostly irrelevant and only
"useful" for checking if we really need to have the scope mapped
Now, the check is rewritten according to K1 semantics
^KT-57694 Fixed
This change is both makes code more consistent with K1 version
and fixes some issues introduced by previous changes
Before this fix, the test
FirPsiOldFrontendDiagnosticsTestGenerated$Tests$Modifiers$Const.testKCallable_after
was failing
^KT-57694 In Progress
Earlier, it wasn't really important but after the previous commit
when JvmMappedScope semantics has been changed, we erroneously
started loading `toCharArray` as a member to String because
its jvmDescriptor was computed to "toCharArray()Lkotlin/CharArray",
while hardcoded information that prevents it from loading expect
"toCharArray()[C" there.
^KT-57694 In progress
Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
Marco Pennekamp