- 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
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
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
Complex enum entries (those with bodies) with missing overrides
are covered by an existing checker that checks all types of classes. But
simple enum entries (those without bodies) were not covered and require
a separate checker for missing overrides.
#KT-58637 Fixed
Base method `RawFirBuilder.Visitor.convertElement` has a parameter with
default value, its overridden one in `VisitorWithReplacement` is not
allowed to declare default. So far so good.
During its work the compiler throws an exception:
`java.lang.IllegalArgumentException: No argument for parameter`.
Prior to this commit code completion for .kts files was supported only
partially. Script has an implicit receiver - base class representing a
script itself, the point where its basic API resides. The knowledge of
this receiver was missing.
There are at least two context where this knowledge is crucial:
1. Code highlighting (worked fine)
2. Code completion (failed)
`FirScriptConfiguratorExtension` is responsible for filling
`FirScriptBuilder` with base script class (in addition to other
properties). See usages of [1] in its implementation.
The thing is that resolution during the completion works a bit
different. Instead of converting the entire `KtFile` it's interested
in `KtScript` only. See usages of [2].
`RawFirBuilder.Visitor.visitScript` is where implicit receivers were
missing.
Code completion and inspections applied to `.kts` files already have
`FirScript` and don't require its full reconstruction with expensive
`FirScriptConfiguratorExtension`. `RawFirBuilder.Visitor` was modified
to support sometimes already existing `FirElement`.
----------------------------------------------------------------
[1]: ScriptCompilationConfiguration.baseClass
[2]: RawFirBuilder.Visitor.convertScript
To be reported with [1] imports require source. It was missing for
implicit script imports.
`FirScriptConfiguratorExtensionImpl` was extended and now adds fake
source elements (users don't see imports in the source code).
Since diagnostics for implicit import statements are meaningless for
IDE, they are suppressed in `LLFirDiagnosticReporter`.
----------------------------------------------------------------------
[1]: DiagnosticReporter.reportOn()
The following two registrars were missing:
- FirScriptingCompilerExtensionIdeRegistrar
- FirScriptingSamWithReceiverExtensionRegistrar
`FirScriptingCompilerExtensionIdeRegistrar` was introduced as a copy of
`FirScriptingCompilerExtensionRegistrar` adapted for usage from IDE.
`FirRegisteredPluginAnnotations` and `FirJvmTypeMapper` are mandatory at
`FirExtensionService.registerExtensions` and reported as missing at
runtime.
Brian Norman