- In parallel to Kotlin declaration provider merging, we need a proper
merging strategy for package providers as well, because resolve
extensions may define additional package providers.
- Additionally, other non-scope-based package providers may be added in
the future, and the merger preserves these out of the box.
^KT-61791
Similar to K1 KDocLinkResolutionService used by Fe10KDocReference (to
support additional KDoc resolution), this commit adds K2 counterpart
AdditionalKDocResolutionProvider and uses it for KDocReferenceResolver.
^KT-62187
- Java combined declared member scopes are implemented as a composition
of the non-static and static scope, so we have to exclude inner
classes from the non-static scope to avoid duplicates.
- This is not an issue for Kotlin combined declared member scopes,
because the combined scope is already the base scope.
^KT-61800
- Comparing the callable ID with the owner's class ID is the simplest
way to check whether a callable is declared inside an owner class.
However, this does not work for local classes, because they do not
have proper class IDs. The same issue occurs when trying to get the
containing class, because it is a lookup tag search in symbol
providers.
- Given that the scope is only needed for Java classes and local Java
classes cannot leak from function bodies, the easiest solution is to
disallow creating this scope for local classes.
^KT-61800
- An inner class `Inner` in a class `Outer` is accessible as
`Outer().Inner()` and should thus be part of the non-static declared
member scope.
- Related issue containing a discussion about inner classes in use-site
scopes: KT-62023.
^KT-61800
- The semantics of a non-static declared member scope should be as
follows: For a variable `c: C` of class type `C`, the declared member
scope should contain all members `x` accessible as `c.x` (visibility
notwithstanding) which are *also* explicitly declared in `C`.
- Classifiers are not accessible as properties of a variable `c`, only
as static members of the class `C` itself, so non-static declared
member scopes should not contain any classifiers.
^KT-61800
- `JavaClassDeclaredMembersEnhancementScope` actually had nothing to do
with Java enhancement, so it is easily replaceable with a more general
`FirDeclaredMembersOnlyScope`.
^KT-61800
- Now that combined declared member scopes for Java classes contain
static callables, we don't need to search symbols in the static member
scope. (Note that the static member scope is too broad for this use
case, as it contains symbols from superclasses, but we only need to
look at declared members because the correct `containingClass` is
already chosen.)
^KT-61901
^KTIJ-25126
- Now that non-static declared member scopes don't contain static
callables anymore, we have to update some usages in the Analysis API.
- In symbol light classes, many usages of `getDeclaredMemberScope` can
be kept as-is because Kotlin classes/objects generally cannot declare
static callables (and we do not need to create symbol light classes
for Java classes). The only exception are enum classes, which
implicitly declare some static callables.
^KT-61800
- Member scopes already don't contain static callables, only their
static member scope counterparts. However, declared member scopes
contained both non-static and static callables, which was confusing to
users. See for example KT-61255.
- Now declared member scopes only contain non-static callables and
static declared member scopes only contain static callables.
- In `KtFirScopeProvider`, the new implementation is different for
Kotlin and Java classes, because the standard declared member scope
doesn't work for Java. Instead, we have to get the Java *enhancement*
scopes from `JavaScopeProvider`. Unfortunately, `JavaScopeProvider`
doesn't have a direct enhancement declared member scope. This results
in a somewhat complex scope structure with the declared members filter
scope around the use-site/static Java enhancement scope, but since the
declared members filtering scope properly reduces the set of callable
names and scopes in general are cached, this shouldn't be an issue.
- `getCombinedDeclaredMemberScope` is introduced as a separate public
function because for Kotlin scopes, we don't actually have to create a
combined scope, as the non-static and static scopes are just filters
around a combined declared member scope provided by the compiler. It's
also important to have a convenient function to get the combined
declared member scope, because some usages explicitly want access to
all declared members (such as symbol light classes).
- This commit also fixes KT-61901, because
`getFirJavaDeclaredMemberScope` now provides a proper static scope for
Java classes, which will be accessible via the combined declared
member scope as well.
^KT-61800 fixed
^KT-61901 fixed
^KT-61255 fixed
it's useful for IDE's features such as write UAST or refactorings
^KT-62302 fixed
Merge-request: KT-MR-12414
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
...by fake-override.
It is error without deprecation cycle because `expect` and `actual`
classes are still in Beta and expected impact of change is negligible.
^KT-62036 Fixed
Recently, 'KtFirCompilerFacility' started to compile files from
dependent modules separately. Until recently, the code fragment was
in the same module as its context, so they naturally went in the same
compilation round. Now a separate 'KtCodeFragmentModule' is created,
so the code fragment case has to be handled explicitly.
This fixes the following groups of tests:
- FirIdeNormalAnalysisLibrarySourceModuleCompilerFacilityTestGenerated
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated (in IntelliJ)
Implement the same behavior as in K1 evaluator. Also see
'IRFragmentCompilerCodegen#codegenFactory' in the IntelliJ project.
The commit fixes the following failing tests in the IntelliJ project:
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$CompilingEvaluator$InaccessibleMembers.testPrivateAnnotationCompanionValue
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$CompilingEvaluator$InaccessibleMembers.testSelfMembers
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$CompilingEvaluator$InaccessibleMembers.testOuterMembers
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$Uncategorized.testPrivateMember
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$Uncategorized.testProperties
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$Uncategorized.testPrivatePropertyWithExplicitDefaultGetter
- K2IdeK2CodeKotlinEvaluateExpressionTestGenerated$SingleBreakpoint$Uncategorized.testPrivateClass
It's implemented as IR checker because in K2 constant expressions are
evaluated on backend. FIR diagnostic removed because isn't needed.
"annotationViaActualTypeAlias" test has no `// FIR_IDENTICAL` because
diagnostic reported on entire typealias declaration instead of its name.
This is because in IR+LightTree we have only offsets, so can't navigate
to typealias name element.
^KT-59940 Fixed
This is more consistent with the code of
the common compiler checkers.
It would be nice to refactor the contents
of this object further, but it's out
of scope of the current branch.
^KT-54596
Backend requires annotation constructors to be fully resolved for the
'IrConst' default value lowering. However, in the IDE there is usually
no need in complete annotation class resolution.
^KTIJ-27061 Fixed
Make `FirShorteningContext` correctly return symbols for type
parameters, so they are not ignored when scopes are inspected
Add additional type of `PartialOrderOfScope` - `TypeParameter`, because
otherwise it would have been classified as `Unclassified`, and that
breaks scopes comparison
Add missing type parameters to the scope of class header in
`ContextCollector`, add testdata for that
There is a bug in the compiler with type parameters leaking to nested
classes headers (KT-61959). After it's fixed, the testData with
incorrect expected shortenings/scopes should be adjusted and fixed too
^KTIJ-27050 Fixed
Dmitrii Gridin