Invocation of Logger.fatal() may cause severe side effects such as
throwing an exception or even terminating the current JVM process
(check various implementations of this function for details).
The code that uses Logger.fatal() sometimes expects a particular kind
of side effect. This is totally a design flaw. And it's definitely not
a responsibility of Logger to influence the execution flow of
the program.
We should provide valid getReferenceName as it is used
in many places (e.g. from com.intellij.psi.impl.PsiImplUtil.findAnnotation)
^KT-61605 Fixed
^KT-64605 Fixed
Because of KT-64743 there is unexpanded type-alias in a place we don't
expect it to occur. To workaround this, we just expand typialiases in
one more place.
^KT-64743
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
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
Dmitriy Dolovov