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
- The compiler's `SealedClassInheritorsProvider` should not be exposed
outside LL FIR, as it is an internal compiler component and also
exposes `FirRegularClass`. `KotlinSealedInheritorsProvider` is an
Analysis API provider for sealed inheritors that accepts a `KtClass`
instead.
^KT-64718 fixed
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
- 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
This way, even if the whole qualifier is not selected, but some of its
parts are, the reference shortener will correctly find and shorten
those parts
^KTIJ-28080 Fixed
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.
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.
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.
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.
Anna Kozlova