The root cause of the exception is that we missed such an element, and
it led to unresolved declaration during iteration over file declarations
^KT-65562 Fixed
Before, auto-completion was based on on-air resolve, and
'FirTowerDataContext' was computed once, during creation of the
dependent analysis session (with using 'FirTowerDataContextCollector').
This allowed to return the context almost instantly, no matter how many
completion candidates there were.
Dangling file resolution doesn't use 'FirTowerDataContextCollector', as
now there is more precise 'ContextCollector'. However,
'ContextCollector' doesn't cache results by itself, and, if asked, it
will compute the same context over and over again. This exact happened
with extension applicability checker.
The optimized implementation maintains a checker object which caches the
computed context. The old end-point is left to give the IDE plugin time
to adapt to the change.
^KTIJ-28445
When encountering multiple available same named types,
resolve all of them together with corresponding extensions.
This aligns well with the current resolve behavior of classes
with the same name (see `SameNameClassesFromStarImports.kt`)
Also, add extra test for resolving the ambiguous type without
the extension function. The behavior is the same - resolve to the
both classes.
Make sure that, when ambiguous, both the package
and the callable/class/property are resolved from
KDoc reference.
Do a slight refactoring of `KDocReferenceResolver`
This behavior is also true for K1
On-air analysis only worked correctly inside declaration bodies, and
required special handling ('analyzeInDependedAnalysisSession()').
Dangling files, the on-air replacement, works seamlessly, and it is
available in all contexts.
- KT-62895 cannot be reproduced on the Analysis API side. Still, it is
useful to add tests here for better coverage in the future.
- The reason is likely that Analysis API tests specifically use
`SealedClassesInheritorsCaclulatorPreAnalysisHandler` to compute
sealed class inheritors (which are usually the breaking point for
problems in `when` exhaustiveness checking), so the tests do not use
the production implementation. See KT-64505 for future work on this
problem.
^KT-62895
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
Anna Kozlova