Parameters, type parameters, and property accessors are not
self-sufficient declarations (their resolution depends on resolution
of their parent), so a proper designation path cannot be computed
for them.
Without a designation path, 'ContextCollector' performs analysis of the
whole file, which is inefficient.
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.
Some components in Analysis API have the 'Impl' suffix both in test
and standalone environments. This commit fixes the logical ambiguity
for a project structure provider.
Before the change, all code fragment sessions were invalidated on any
PSI change. It was a simple solution, though not very effective.
Fragments were invalidated not only on a physical module change, but
also on change in another, unrelated code fragment.
As code fragment sessions were reworked to support also ordinary '.kt'
files, the old logic started to have even less sense, because ordinary
dangling files do not have a context element (they only have a context
module).
Currently, code fragment sessions are invalidated on any change in a
physical (non-dangling) module, and are also invalidated on any change
in their contextual dangling module, if any. With some work, this can be
improved further, so code fragments will be invalidated only on changes
in modules they depend on.
Relevant tests can be found in the IntelliJ project
(DanglingFileModuleInvalidationTest).
In 'getFirForNonBodyElement()', a wrong 'FirProvider' was used for
elements from modules other than a use-site one, and it could lead to
"Modules are inconsistent" exceptions from 'LLFirFileBuilder'.
Dangling files are copies of files in the context module, or just
depend on it. In any way, dangling file modules see all internals of
the context module.
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.
Normally, 'bindSession()' is called on a 'FirModuleData' right after its
instantiation to make it fully initialized. For source sessions,
this is done directly during the session creation. However, module data
created for dependencies (see 'LLFirModuleData.dependencies' & friends)
stay uninitialized, breaking 'collectAllDependentSourceSessionsTo()'.
The previous implementation in 'TestModuleStructureFactory' had very
custom and redundant logic for binary dependency collection.
In particular, JDK and kotlin-stdlib were specifically computed,
although both already were in the module classpath, which was handled in
'createLibrariesByCompilerConfigurators()'. In addition, there was no
support for common modules.
The new behavior is much closer to what happens in production.
- If the `sealed` modifier is not kept in the interface's stub, a
sealed interface will have an `abstract` modality instead, which
causes issues with `when` exhaustiveness analysis in K2.
- This issue also affected K1, but it was less visible there because
`when` exhaustiveness analysis in K1 uses deserialized descriptors.
^KT-62895
We shouldn't build expect declarations as they do not
exist. We can omit check on member declarations as we
won't request them as we skip expect classes
^KT-57536 Fixed
Multifile-class can contain not only files from the same
module, but also files from the common part.
This commit also fixes KotlinByModulesResolutionScopeProvider as
it should provide all transitive dependencies
^KT-64714 Fixed
To call retrieveDirectOverriddenOf,
one must use directly the owner scope of a callable symbol we consider,
and not a scope of some derived class.
#KT-64276 Fixed
Make sure SENSELESS_COMPARISON
is absent in this case.
^KT-64089 Obsolete
Merge-request: KT-MR-13754
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
It started failing because of other
changes having been merged right before it
^KT-64644 Fixed
Merge-request: KT-MR-13755
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
These methods are only added to provide more user-friendly error
when user tries to configure JVM toolchain in Kotlin target DSL.
^KT-64629 Verification Pending
Yan Zhulanow