In the 'IGNORE_SELF' mode, dangling files don't have their own
declarations in providers. As a result, all references there resolve to
declarations of the original file. It is conceptually similar to that we
had in on-air resolve, however, now it's possible to work with the whole
content of the in-memory 'FirFile'.
As it can be seen in 'ProjectStructureProvider.kt'
(KtFile.danglingFileResolutionMode), the 'IGNORE_SELF' mode is
automatically applied for non-physical files with an original file being
set. For other scenarios, now there is a new 'analyzeCopy()' function
that allows to pass the analysis mode explicitly.
PSI events do not arrive for dangling files with no backing
'VirtualFile', so its partial invalidation becomes non-trivial.
In the change, a short-living cache is implemented for these 'unstable'
dangling files.
This commit introduces dangling file modules, which may be either
code fragments or ordinary Kotlin files. As before, code fragments are
analyzed against some context element, however ordinary files only
have a context module.
Code fragments can also have a dangling file module as a contextual one,
including other code fragment. This is done to support potential usages
in completion, intentions and refactorings.
- 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.
Before, `KtCodeFragment`/`FirCodeFragment` was analyzed as a part of
its context `KtModule`. This has the following complications:
- In non-source sessions, diagnostic reporting is globally disabled.
For code fragments, however, checking the code before passing it to
the backend is essential.
- Special treatment for call ambiguities in libraries
(`LLLibraryScopeAwareCallConflictResolverFactory`) becomes complicated
as the conflict resolver has to be applied to a library module.
- `KtCodeFragment`s usually have a shorter lifetime than their own
context. Caching may potentially be implemented differently for them.
^KT-61783 Fixed
- 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.
- `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 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.
In certain cases, it's impossible to determine which module owns a
particular file without knowing the analysis context. For instance,
the file might be a part of a physical module, and be also included into
a virtual ad-hoc module (to be analyzed in separate, e.g. a VCS diff).
The new API allows to pass a contextual module. Basically it means
"give me a module for this element, implying that we are now analyzing a
contextual module".
^KT-57559 Fixed
The problem results in broken import quick fix and import optimizer on
the IDE side [1].
`AssignResolutionAltererExtension` introduced a possibility to override
resolution of assignment statements. The inconsistency though is
that `KtSimpleNameReference.getResolvesByNames` doesn't return a name
for the overridden `=`. Kotlin as a language doesn't support this [2].
This commit eliminates the drawback above:
1. It fixes the name `assign` the `=` can be resolved to [3].
This eliminates the need to search for the name, bypassing the
plugins.
2. `KtSimpleNameReference.getResolvesByNames` returns `assign` among
other names in case it deals with binary `=` and assignment is
resolved.
3. `KtCompilerPluginsProvider` was extended to check plugins' presence.
K1 implementation added.
----------------------------------------------------------------
[1]: https://youtrack.jetbrains.com/issue/KTIJ-24390
[2]: OperatorConventions.getNameForOperationSymbol
https://kotlinlang.org/docs/operator-overloading.html#augmented-assignments
[3]: OperatorConventions#ASSIGN_METHOD + AssignmentPluginNames
This will allow IDE plugins to contribute compiler plugins to analysis,
above and beyond those used for the actual compilation step. These
plugins can be used to, for example, provide declarations for code that
is generated during build by an external tool.
^KT-57763 fixed
- 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
Indices are not available in the IDE for files outside content roots,
and the newly introduced 'PsiFile' can be used for searching
classifiers instead.
Instead, provide an option to register PSI declaration provider inside
Analysis API session builder where we can retrieve all necessary pieces,
including CoreJarFileSystem, PackagePartProvider, and binary modules
from internal project structure provider.
We do not know for sure if there is any dependency between the
two classes passed to `checkIsInheritor`. To avoid the problem described
in KT-51240, we try to analyse them both and hope that the dependency
in some direction exists.
`NoCacheForModuleException` is introduced to signal about this
particular problem and avoid catching just any `NoSuchElementException`.
This hack is mainly done to fix very annoying KT-51240 for the time
being.
^KTIJ-20852 Fixed
Yan Zhulanow