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.
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.
- This commit adds a `MODULE_KIND` directive to Analysis API tests which
can be used to change a test module's `KtModule` kind from the default
determined by the test's registered `KtModuleFactory` (which in turn
depends on the `moduleKind` configured during test generation).
- The most important use case is the ability to have multi-module tests
where a main module references symbols from a binary library module.
This use case requires source configurations to compile libraries,
which requires additional setup. This will be implemented in a
following commit.
^KT-64468 Fixed
- Old backend support is not needed in `KtFe10CompilerFacility` anymore,
because it has been removed for the bytecode tool window, which was
the only user. The old backend is slated to be removed entirely.
^KTIJ-24522
At the moment, there is no good way to meaningfully filter `this`
expressions. The filters for the reference shortener can work only with
symbols, and it does not make a lot of sense to check any particular
symbol when deciding whether to shorten a labeled `this` expression.
We would probably need a better API for the shortener to be able
to filter more precisely (see KT-63555)
^KT-62675 Fixed
- `testConflictingOverloadsAtTopLevel` is currently disabled in FIR
because it fails with a mismatch between diagnostics from the file and
the individual elements. It will be enabled in the next commit.
^KT-62899
The existing reference shortener does not use import alias when it
shortens a symbol. Instead, it adds a new import directive for the
symbol that is already imported. This commit updates reference shortener
to let it reuse the existing import alias rather than adding a new one:
1. When shortening a symbol, check whether the symbol is already
imported.
2. If it is already imported by an import alias, keep the symbol
reference expression and the import alias as a string together in
`ShortenCommand`.
The actual PSI update (shortening) based on the ShortenCommand is done
by IntelliJ.
^KTIJ-27205
This is required for some checks on call site, and it seems that
this symbol can cover all cases.
One of the examples why this API was introduced is a request to
distinguish which vararg parameter is missed in arguments
of an annotation call from symbol light classes
^KT-62560
^KTIJ-27522 Fixed
It's the only reasonable behavior for this API in it's current shape
(when it returns a list of declarations)
It's a common mistake to take only Compatible from
expectActualMatchingMap. The problem will be gone after I fix KT-62590
Motivation to fix this bug, is because it will be easier for me to split
expect-actual matcher-checker-monster thing KT-62590
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
This class should contain 'global' settings for reference shortening;
ATM it only contains the `removeThis` flag
In the future this setting might be merged together with
`ShortenStrategy` to be computed on per-element basis
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62957 fixed
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62010 fixed
As of now, this implementation is not supposed to be used at all
If (for some reason) it becomes relevant again, please refer
to the 7fd441f1 commit which contained a FE10 implementation
of this service (copied from the old FE10 implementation of
import optimizer)
We don't plan to seriously support the FE10 implementation of
`KtImportsOptimizer` service, since it's not going to be used in IDE
(it has its own old version of import optimization logic)
- This adds KDoc reference resolution tests for callables in nested and
inner classes, overloaded functions, and private callables.
- Private declarations are visible in KDoc from outside their containing
classes. This is in line with K1 KDoc behavior.
^KTIJ-22324
Mikhail Glukhikh