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
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>
Utilize `FirSamResolver` to obtain the potential SAM constructor
from the classifier
Also, accept K2_SYNTHETIC_RESOLVED in the `resolveUnqualifiedAccess`,
since this is the kind of resolve success which corresponds to the
SAM constructor call resolution
^KTIJ-28167 Fixed
This allows to properly report them as used in `KtFirImportOptimizer`
This change will also be important for properly fixing KTIJ-28167,
since `computeImportableName` is also used in reference shortener
^KTIJ-28385 Fixed
Java resolving subsystem requires calculated visibility for correct disambiguation of supertypes.
But visibility remains `Unknown` for Kotlin class-like declarations during supertypes resolving because `STATUS` resolve phase is performed after `SUPER_TYPES` phase.
To fix the problem, the visibility should be initialized to public at the FIR building phase if no modifier is presented.
^KT-64127 Fixed
We don't have true flexible types in the IR, but we approximate it with
internal type annotations, such as FlexibleNullability,
FlexibleMutability, RawType. These annotations are then handled
specially in JvmIrTypeSystemContext, which can construct a fake flexible
type so that type checker on IR types would behave exactly as on
frontend types.
As shown in KT-63441, one instance of flexible types where flexibility
was lost during conversion to IR is Java array/vararg types. It's
necessary to support it so that IR fake overrides could be constructed
correctly, because IR fake override checker requires parameter types to
be equal. So this change introduces another internal type annotation,
FlexibleArrayElementVariance, which is only applicable to types with
classifier kotlin/Array, and which signifies that the annotated type
`Array<X>` should rather be seen as `Array<X>..Array<out X>`.
#KT-63441 Fixed
#KT-63446 Fixed
findClasses works over regular `PsiElementFinder`, which doesn't know
about out ClassId conception. So, `a/b/A.B` and `a/b/A/B` are the same
from `FqName` point of view.
`FirJavaFacade` has this check, so this problem appears only in the case
of combined provider.
^KT-62892 Fixed
Previously we just skipped Java sources.
The order of classes in light classes test data is changed due to
differences in implementations of `compileLibraryToJar` and `runJvmCompiler`
^KT-62892
As it is more similar to production. Also, fixed scope search for klib.
Now we register main binary modules before to avoid duplication with
libraries from createLibrariesByCompilerConfigurators as now we can
have a declared library and regular sources
^KT-62888
^KT-62651
Yan Zhulanow