According to
`FirNativeCodegenBoxTestGenerated.testNestedClassesInAnnotations`,
the annotation
`kotlin.internal.PlatformDependent` is
unresolved reference.
^KT-58549 Fixed
- Due to KTIJ-25562, combined stub-based deserialized symbol providers
currently create code correctness issues and should thus not be
enabled.
- Once that issue is fixed, KT-58325 should be revisited.
- `dependency2` is needed to ensure the creation of combined Kotlin
symbol providers. If there is only a single dependency Kotlin symbol
provider, the combined symbol provider won't be created.
- To test the reference resolution of declarations provided through
resolve extensions of module dependencies, we need support for
multimodule resolve extension tests.
- A proper merging strategy for declaration providers is required for
cases where the main declaration provider created by
`createDeclarationProvider` can't provide all declarations that the
original declaration providers can provide. Then, only a sublist of
the declaration providers should be merged, while keeping the
unmergeable declaration providers intact.
^KT-58580 fixed
- `KtNotUnderContentRootModuleForTest.directRegularDependencies` is
called during project structure creation, which led to builtins
session creation during that period. This in turn led to the creation
of `JvmStubBasedFirDeserializedSymbolProvider`, which failed upon the
initialization of `declarationProvider` because
`KotlinDeclarationProviderFactory` wasn't registered yet. This is
precisely why `declarationProvider` was made lazy.
- However, with the new `FirSymbolNamesProvider`, keeping
`declarationProvider` lazy is harder, because `symbolNamesProvider`
(if also made lazy) is requested during composite symbol provider
creation in `createBuiltinsAndCloneableSession`.
- The solution avoids creating the builtins session entirely. Instead,
`directRegularDependencies` now gets the `KtBuiltinsModule` directly,
which is more straight-forward as well.
- 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.
Nikolay Lunyak