- `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.
- 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.
Without the fix, all libraries share the global scope for all project
libraries. JDK_HOME was used implicitly for things such as providing
Record support, but was not included as a test library/sdk.
KT-59637
- 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.
merging `LLFirSelectingCombinedSymbolProvider.selectFirstElementInClasspathOrder`
relies on the fact that a candidate belongs to exactly one module.
This can be not true for libraries, attached to multiple modules.
In that case we need to accept "wrong module" to retrieve correct provider
- In contrast to other kinds of dependencies, `dependsOn` dependencies
must be followed transitively.
- Add `transitiveDependsOnDependencies` to `KtModule`. These
dependencies are calculated lazily with a topological sort. They are
added to the dependency provider when it's built in
`LLFirSessionFactory`.
^KT-55329 fixed
As 'initialiseVirtualFileFinderServices()' that is run during
test initialization collects transitive dependencies, all of them
must be ready. However, 'KtNotUnderContentRootModuleForTest' has a
built-in dependency provided by 'LLFirBuiltinsSessionFactory'.
- Move out getAnalyzerServices from FirFrontendFacade to TestSetupUtils
- Simplify DependencyListForCliModule. Now it takes BinaryModuleData as input
- FirOutArtifact contains several FirOutputArtifactPart
- Simplify FirFrontendFacade
Before, the only way of getting analyzable elements was to create an
analyzable file by using 'createAnalyzableFile()'. So made all utilities
available in 'KtPsiFactory' useless as they delegate to 'createFile()'
that always set the 'doNotAnalyze' flag.
The new behavior is to pass the 'analysisContext' instead if it is
passed to the 'KtPsiFactory' constructor.
The newly appeared API is going to be used in the Kotlin's UAST
implementation.
Many sub tests are implementing the same name, doTestByFileStructure,
which indeed are based on the list of KtFile in a single module.
Rather, this one should be named after "ModuleStructure".
Ilya Kirillov