- Since this documentation was written, the usages of contextual modules
have expanded beyond outsider files, for example to support `KtModule`
disambiguation for library elements. Hence, it was necessary to update
the documentation accordingly.
- This is in line with the API of `FirSymbolNamesProvider`. It only
makes sense to compute package sets for source and library modules.
Also, source module package set computation in the IDE is currently
broken, so it's good to be able to return `null` in the meantime.
- This also allows the removal of the workaround for source modules in
`LLFirProviderHelper`, as the IDE declaration provider can now return
`null` itself in this case.
^KTIJ-27411
- This will allow the Kotlin declaration provider to compute package
sets based on the library module associated with the stub-based symbol
provider.
^KTIJ-27411
- This is more consistent with "top-level callable names in package" and
simplifies the set construction quite a bit, as we can avoid a lot of
`asString` conversions.
- `LLFirProviderHelper` is guarded by `allowKotlinPackage` and the
symbol names provider should reflect that in the name sets.
- Note that this does not apply to stub-based deserialized symbol
providers, because they do not pass any value to `allowKotlinPackage`.
^KT-57314
- This adds KDoc reference resolution tests for callables in nested and
inner classes, overloaded functions, and private callables.
- Private declarations are visible in KDoc from outside their containing
classes. This is in line with K1 KDoc behavior.
^KTIJ-22324
- We should use member scopes to find symbols from supertypes.
- The issue was already fixed for static callables because the declared
member scope was composed with the static member scope. See
KTIJ-25960.
^KTIJ-26003 fixed
This further improves the `KotlinCompositeProvider` abstraction:
- Pulling the abstraction's interfaces outside the `impl` package allows
us to write consolidated documentation on composable Kotlin providers.
- The addition of `KotlinComposableProvider` allows more specific bounds
for the type parameters of `KotlinCompositeProvider` and
`KotlinCompositeProviderFactory`. It also clarifies to Analysis API
implementors which providers can be composed at all, as providers like
`KotlinDeclarationProvider` extend this interface.
- `KotlinComposableProviderMerger` provides a unified interface for
provider mergers.
^KT-61791
- In parallel to Kotlin declaration provider merging, we need a proper
merging strategy for package providers as well, because resolve
extensions may define additional package providers.
- Additionally, other non-scope-based package providers may be added in
the future, and the merger preserves these out of the box.
^KT-61791
- Composite declaration providers and declaration provider mergers are
extremely similar to the composite package providers and (newly to be
implemented) package provider mergers. This commit extracts the common
parts into a `KotlinCompositeProviderFactory`.
^KT-61791
- `getPackage` can also benefit from a combined index access.
- Care has to be taken with allowed/disallowed `kotlin` packages. Since
we're not delegating to individual symbol providers after the index
access, `allowKotlinPackage` has to be taken into account in the
combined symbol provider explicitly.
^KT-61791 fixed
- Java combined declared member scopes are implemented as a composition
of the non-static and static scope, so we have to exclude inner
classes from the non-static scope to avoid duplicates.
- This is not an issue for Kotlin combined declared member scopes,
because the combined scope is already the base scope.
^KT-61800
- Comparing the callable ID with the owner's class ID is the simplest
way to check whether a callable is declared inside an owner class.
However, this does not work for local classes, because they do not
have proper class IDs. The same issue occurs when trying to get the
containing class, because it is a lookup tag search in symbol
providers.
- Given that the scope is only needed for Java classes and local Java
classes cannot leak from function bodies, the easiest solution is to
disallow creating this scope for local classes.
^KT-61800
- An inner class `Inner` in a class `Outer` is accessible as
`Outer().Inner()` and should thus be part of the non-static declared
member scope.
- Related issue containing a discussion about inner classes in use-site
scopes: KT-62023.
^KT-61800
- The semantics of a non-static declared member scope should be as
follows: For a variable `c: C` of class type `C`, the declared member
scope should contain all members `x` accessible as `c.x` (visibility
notwithstanding) which are *also* explicitly declared in `C`.
- Classifiers are not accessible as properties of a variable `c`, only
as static members of the class `C` itself, so non-static declared
member scopes should not contain any classifiers.
^KT-61800
- `JavaClassDeclaredMembersEnhancementScope` actually had nothing to do
with Java enhancement, so it is easily replaceable with a more general
`FirDeclaredMembersOnlyScope`.
^KT-61800
- The function is mostly for convenience, but scope providers will be
able to optimize this scope if needed (similar to how combined
declared member scopes are already optimized).
- `getCombinedMemberScope` will be used by `KDocReferenceResolver`.
^KT-61900
- Now that combined declared member scopes for Java classes contain
static callables, we don't need to search symbols in the static member
scope. (Note that the static member scope is too broad for this use
case, as it contains symbols from superclasses, but we only need to
look at declared members because the correct `containingClass` is
already chosen.)
^KT-61901
^KTIJ-25126
- Now that non-static declared member scopes don't contain static
callables anymore, we have to update some usages in the Analysis API.
- In symbol light classes, many usages of `getDeclaredMemberScope` can
be kept as-is because Kotlin classes/objects generally cannot declare
static callables (and we do not need to create symbol light classes
for Java classes). The only exception are enum classes, which
implicitly declare some static callables.
^KT-61800
- Member scopes already don't contain static callables, only their
static member scope counterparts. However, declared member scopes
contained both non-static and static callables, which was confusing to
users. See for example KT-61255.
- Now declared member scopes only contain non-static callables and
static declared member scopes only contain static callables.
- In `KtFirScopeProvider`, the new implementation is different for
Kotlin and Java classes, because the standard declared member scope
doesn't work for Java. Instead, we have to get the Java *enhancement*
scopes from `JavaScopeProvider`. Unfortunately, `JavaScopeProvider`
doesn't have a direct enhancement declared member scope. This results
in a somewhat complex scope structure with the declared members filter
scope around the use-site/static Java enhancement scope, but since the
declared members filtering scope properly reduces the set of callable
names and scopes in general are cached, this shouldn't be an issue.
- `getCombinedDeclaredMemberScope` is introduced as a separate public
function because for Kotlin scopes, we don't actually have to create a
combined scope, as the non-static and static scopes are just filters
around a combined declared member scope provided by the compiler. It's
also important to have a convenient function to get the combined
declared member scope, because some usages explicitly want access to
all declared members (such as symbol light classes).
- This commit also fixes KT-61901, because
`getFirJavaDeclaredMemberScope` now provides a proper static scope for
Java classes, which will be accessible via the combined declared
member scope as well.
^KT-61800 fixed
^KT-61901 fixed
^KT-61255 fixed
- Previously, `KtFirAnonymousObjectSymbol` was a
`KtEnumEntryInitializerSymbol`, which carried the risk that an
anonymous object unrelated to enum entries might be used as an enum
entry initializer. This commit introduces a specific symbol for FIR
enum entry initializers.
- As a nice side effect, anonymous object symbol creation is simplified
and `KtFirEnumEntryInitializerSymbolPointer` can restore the symbol
via `KtFirEnumEntrySymbol.enumEntryInitializer`.
^KT-61425
- Now that the enum entry initializer provides a member scope, not the
enum entry, we need a way to get to the enum entry initializer in
tests. This can only be done via the enum entry's name, because the
initializer is anonymous.
^KT-61425
- An enum entry's body is an initializer with members only accessible
within that body. Because users of the Analysis API might want to
analyze the members of the enum entry initializer, we expose this
initializer via `KtEnumEntrySymbol`. The initializer only exists if
the enum entry has a body.
- We already have some usages of the initializer inside symbol light
classes, which generate a light class for each enum entry, which
includes the enum entry's hidden members.
- To hide the implementation detail that initializers are anonymous
objects, `KtEnumEntryInitializerSymbol` is simply a
`KtSymbolWithMembers`.
- The advantage of making it a `KtSymbolWithMembers`, instead of
providing a custom way to get a member scope, is that we can pass
around the initializer easily, e.g. in `KtEnumEntrySymbolRenderer`.
- We implement `KtEnumEntryInitializerSymbol` directly as a
`KtFirAnonymousObjectSymbol` without a wrapper. This has a few
advantages:
1. We can directly benefit from the anonymous object symbol being a
`KtSymbolWithMembers`, so we don't have to handle enum entry
initializers specially in e.g. `KtFirScopeProvider`.
2. We don't have to implement a new symbol restoration mechanism for
the initializer.
3. This implementation matches the actual FIR tree structure (with a
simplification that the connecting anonymous object expression
between the enum entry and the initializing anonymous object is
omitted).
^KT-61425 fixed
- An enum entry is a variable which doesn't declare any additional
members. It must not be confused with its implementing anonymous
object initializer, which may declare additional members, but is an
implementation detail hidden outside the enum entry's initializer.
Hence, the enum entry variable should not have a (declared) member
scope.
- A following commit will add the ability to get the enum entry's
initializer, so that a member scope for this initializer can be
obtained (which might be relevant for local analysis).
^KT-61405 fixed
- The implementations of some FIR scopes contain a significant amount of
delegation to some original scope. This pollutes the implementation of
such scopes and makes them harder to read.
`FirDelegatingContainingNamesAwareScope` and `FirDelegatingTypeScope`
can be used as base classes which delegate by default.
- `getConstructorKeyword` forces an AST load due to a child search. In
most cases, we don't need to check the constructor keyword in primary
constructors at all (e.g. `class ABC()` with an implicit primary
constructor). The keyword check is only needed when there are primary
constructor modifiers (e.g. `class ABC constructor()`).
Thanks to Dima Gridin for the suggested fix.
^KT-61635 fixed
- `KtReadActionConfinementLifetimeToken` tracks its validity via the
project-wide out-of-block modification tracker. Out-of-block
invalidation of some LL FIR session will cause the lifetime tokens of
all analysis sessions to become invalid, including unrelated sessions,
because of this project-wide tracking.
- If `KtFirAnalysisSession`s are only invalidated when their underlying
LL FIR session is invalidated, the cache may expose analysis sessions
which contain invalid lifetime tokens after out-of-block modification.
Even though an analysis session will still be practically valid if its
underlying LL FIR session is valid, the lifetime token will *think*
that the PSI has changed and throw an "access to invalid token"
exception.
- Hence, we cannot currently invalidate `KtFirAnalysisSession`
granularly and project-wide OOBM tracking needs to be restored.
^KT-60272
- Due to problematic timing in `LLFirSession.invalidate` when the
function is called from a read action, it's better to remove the
function altogether.
- The function's only usage was session invalidation after exceptions
from resolve when FIR tree guards were turned off. Because FIR tree
guards are stable enough, the flag that turned them off can be
removed. This also allows removing `LLFirSession.invalidate`.
- The alternative to removing `LLFirSession.invalidate` would be to
rewrite session invalidation to be independent of write actions. That
would require additional locking in `LLFirSessionCache`, which we want
to avoid.
^KT-59297
- Module state modification events now have a modification kind, which
allows adding additional kinds of modification in the future (e.g.
separating module property and content root updates, if the workspace
model ever supports it).
- Splitting off modification kinds was also a good opportunity to
better document when module state modification occurs.
- Changed the documentation of modification events to be (1) less
reliant on the IDE implementation and (2) more detailed in the
intended effect of each event.
- Removed the notion of "stable" modules again and replaced it with
"libraries". Even though an SDK is technically not a library, the
term "library modules" should be more friendly to API consumers.
- Specifically for non-global module state modification, we can
guarantee that the event is published before the module is modified.
This allows subscribers to use the provided `KtModule` without needing
to fear that the module has already been disposed (in case of
removal).
- `KtFirAnalysisSession` does not need to depend on project out-of-block
and project root modification trackers anymore, as its underlying
use-site session determines validity. To ensure that use-site sessions
are invalidated in SLC equality tests, modification events also need
to be published.
- We do not need `AtomicBoolean` here, because setting `_isValid` to a
constant `false` suffices.
- Also replace the public setter of `isValid` with `markInvalid` to
prohibit setting `isValid` to `true` again.
- Out-of-block modification of stable modules is meaningless, because
stable modules should not be affected by out-of-block modification.
Hence, only global *source* out-of-block modification makes sense and
global out-of-block modification events can be removed.
- Any time an anchor module's session is invalidated, we need to make
sure that all its dependents are also invalidated. Because those
dependents may include libraries, invalidation after global source
modification needs to invalidate such libraries, even if other stable
module sessions should remain untouched.
- `LLFirSessionCache.sourceCache` can contain library and library
sources sessions. However, global source modification events should
not remove such sessions from the cache, because they belong to
"stable" modules.
- The commit introduces the term "stable module" as a combined term for
binary and library source modules. Library sources are not binaries,
but nevertheless they cannot cause nor be affected by out-of-block
modification.
- The term "source modules" as used by global "source" modification is
slightly imprecise, as it does *not* include library sources, but for
the sake of conciseness, I don't plan to change that.
- The lambda passed to `invokeLater` in `LLFirSession.invalidate` might
survive beyond project disposal (especially in tests), so me must not
capture a hard reference to the session that can leak its `project`.
- Until the IDE module dependents provider has been implemented for
script dependents (see KTIJ-25620), we must assume that any script
modification may lead to any other script session being out of date.
Hence, script modification now leads to the removal of all script
sessions.
- Because the IDE module dependents provider doesn't provide script
dependents for libraries yet, library modification must also lead to
global script session invalidation.
- We don't need to invalidate dependent sessions when the root session
isn't in the session cache, or if the session is already marked as
invalid, because any dependent sessions that might exist won't be
referencing entities from the root session at that point.
- Because `KtModule`s and thereby sessions may depend on each other
cyclically, we must not create a session during the creation of
another session. Otherwise, let's say session A and B depend on each
other. Then we get the following nested creation: session A -> session
B -> session A -> session B, and so on.
- Dependency symbol providers are in part taken from dependency
sessions. Hence, we have to create dependency symbol providers lazily.
- For the creation of dependency symbol providers we only need to access
the non-dependency symbol providers of a session dependency, so we
don't need to access the dependency's dependency symbol providers.
Hence, the lazy construction won't run into issues with cycles later
on.
^KT-57743 fixed
- Kotlin modification events are published before or after the
modification, depending on the underlying cause. For example, PSI tree
change events in the IDE can occur both before and after the change,
so module and global out-of-block modification events must not make
timing guarantees. Similarly, module state modification events
published by the IDE can both happen before and after a module change,
with most events happening before the change.
- This commit replaces session modification trackers with event-based
session invalidation. The removal of modification trackers should
improve overall performance, because session invalidation events
happen less frequently than sessions are accessed. Getting rid of
modification trackers also allows sessions to refer to other sessions
lazily, which is essential when cyclic dependencies occur.
- The new `LLFirSession` validity tracker has constant complexity and
will not cause the same kind of performance issues as dependency
modification trackers. It is a bridge to support modification trackers
in certain parts of the code (e.g. for `CachedValue`s), while being
backed by event-based invalidation.
- `LLFirSessionInvalidationService` is the bridge between modification
events and `LLFirSessionCache`. It finds out which modules should be
invalidated and instructs the session cache to remove the associated
sessions.
- Session invalidation must always happen in a write action to preserve
consistency between sessions. Otherwise, while a session A is already
removed from the cache, it might still be referenced by a dependent
session B which is in the process of being invalidated. Such a session
must never be returned from `getSession`.
^KT-57515 fixed
- The IDE implementation of `KotlinModuleDependentsProvider` cannot
easily find all dependents for a builtins or SDK module. Instead,
builtins and SDK changes can be handled via global module state
modification events, because most modules will depend on builtins and
SDK modules.
- Event-based session invalidation requires knowledge about the
dependents of a `KtModule`. This is because, when the session for a
module is invalidated, all sessions for modules which depend on that
module, directly or indirectly, must also be invalidated.
- Note that the approach with modification trackers relied on module
dependencies. Events have an opposite flow of information compared to
modification trackers: Modification trackers request whether a change
occurred, while events publish that a change occurred. Thus, the
modules which need to be incorporated into the invalidation dynamic
are also flipped: dependents instead of dependencies.
- `KotlinModuleDependentsProvider` is designed to work generally. It can
be used for purposes beyond session invalidation.
- `registerServicesForProjectEnvironment` relied on lists of all modules
and source files, which the standalone project structure providers
would have already been able to provide with the right interface.
- In `StandaloneAnalysisAPISessionBuilder.build`, to get all modules and
source files, `projectStructureProvider` had to be hard-casted to
`KtModuleProviderImpl`.
- This commit introduces `KtStaticProjectStructureProvider`, a shared
interface for project structure providers with static module
structures that know about their modules and source files.
- `KtResolveExtension`s need to participate in active invalidation,
because LL FIR sessions depend on changes in resolve extension files.
- The resolve extension will simply be able to use the
`KotlinModificationSubscriptionService`, which is part of the Analysis
API surface for **API implementors**, to publish modification events.
- The commit refactors some modification trackers previously provided by
`KotlinModificationTrackerFactory` to a subscription-directed
mechanism implemented via `MessageBus` and `KotlinTopics`. The
following modification trackers are affected:
- Module out-of-block modification: The FE10 Analysis API doesn't use
these modification trackers, so the effect is limited to LL FIR.
- Module state: Likewise, FE10 doesn't use this modification tracker,
so again the effect is limited to LL FIR.
- Project and library modifications trackers remain, because many small
objects in e.g. light classes depend on these trackers (making
listener management unfeasible), and they are not relevant for
`LLFirSession` invalidation.
- This new API paves the way for a session invalidation service to
subscribe to out-of-block and module state changes as events. This
removes the need to iterate through modification trackers.
- Also note that the out-of-block modification provided by the new
subscription mechanism is intended to work for _any_ `KtModule`, as
long as it makes sense to have out-of-block modifications. For
example, the subscription should work for script modules. The OOB
modification tracker previously only supported `KtSourceModule`s,
which required separate single-file modification trackers for script
and not-under-content-root modules.
- `MessageBus` is a general utility provided by IntelliJ, but usually it
is retrieved from `project`. To keep these two concerns decoupled,
`project.messageBus` should not be used directly. Instead, the commit
adds a `KotlinMessageBusProvider`, which for now just provides the
project message bus with its standard implementation, but allows
swapping out the message bus implementation later.
- Global changes are also supported by the new subscription API. Such
global changes may for example occur during cache invalidation in
tests, on global PSI tree changes, or when an SDK is removed.
- Test-only invalidation has been moved from
`KotlinModificationTrackerFactory` to a new
`KotlinGlobalModificationService`. This creates one central service
for invalidation between tests, which is easier from an implementation
and a usage perspective than calling multiple scattered services and
providers.
- As mentioned in KT-60570, memory consumption in cached symbol names
providers is caused partially by lots of instances of empty mutable
sets. This commit replaces such sets with the `emptySet()` singleton.
- This improvement also makes sense for callable names because the IDE
"package names with top-level callables" set currently contains all
package names in the project.
- In my local tests of the `setUp` Find Usages performance test, the
retained size of `FirDelegatingCachedSymbolNamesProvider` is cut down
from 208MB to 170MB by the empty class name set optimization, and from
170MB to 115MB by the empty callable name set optimization.
- Due to the fixes for KTIJ-23584, when calling the UAST conversion
`convertDeclarationOrElement` from `BaseKotlinConverter` (intellij
project) for an SLC/ULC property, `convertDeclaration` failed because
the declaration is "special". This caused `convertPsiElement` to be
tried instead, which also returned `null`, causing the "failed to
convert element" exception described in KTIJ-25335.
- In parallel to the solution for KTIJ-23584, which fixed the special
names issue for functions, this commit skips UAST field generation for
properties with special names.
^KTIJ-25335 fixed
^KTIJ-24121 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.
Marco Pennekamp