- 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 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
- 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).
- 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.
- 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.
- 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.
Use existing stub-based JVM library symbol provider for .knm and
.kotlin_metadata files. The only real difference is the scope filtering
by file types
KT-58769
- 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
this gives the following benefits:
1. no protobuf in memory, all data is already present in stubs
2. given that symbol provider for libraries is already stub based,
we can get rid of complicated code to find source psi by deserialized fir
3. it's also possible to reduce number of index access,
when fir is requested for given ktElement
^KTIJ-24638
Notice on `DebugSymbolRenderer`:
stub based deserializer sets source directly,
but it's available in IDE mode only.
Thus, standalone and IDE tests have different results.
In order to avoid this, sources for compiled code are explicitly ignored
Notice on distinct callables:
for a file which belong to multiple libraries, decompiled code would be build per library.
In order to avoid ambiguity errors for members in that file,
we need to distinct provided elements by origins
failed test from IJ repo:
FirReferenceResolveWithCrossLibTestGenerated#testSetWithTypeParameters
- In performance tests, modification trackers were incorrectly
incremented between tests for binary modules even with library caches
enabled. The new option `includeBinaryTrackers` can be used by
performance tests to exclude binary modules.
Previously, we queried heavy kotlin package provider two times which affected performance
Now it's being queries only a single time
Also, the commit introduces separation for KotlinPackageProvider between kotlin and platform-specific packages
^KTIJ-24640
Ilya Kirillov