We only see the redeclaration
diagnostics on the declarations inside
the second file, because of
`FirRecorder::visitRegularClass`.
`data.state.classifierContainerFileMap`
references the last file, so
when checking the visibility of
the first `private class C { ... }`
(when collecting declarations that
conflict with the second `private class C`)
the provider returns the second file
instead of the first one, so the class
behaves as it is visible, and
`collectTopLevelConflict` returns in
this case.
As for why `INVISIBLE_*`s are reported
inside the first file: this is because
`data.state.classifierMap` stores the
last classifier it sees instead of
the first one.
^KT-62537
This further improves the `KotlinCompositeProvider` abstraction:
- Pulling the abstraction's interfaces outside the `impl` package allows
us to write consolidated documentation on composable Kotlin providers.
- The addition of `KotlinComposableProvider` allows more specific bounds
for the type parameters of `KotlinCompositeProvider` and
`KotlinCompositeProviderFactory`. It also clarifies to Analysis API
implementors which providers can be composed at all, as providers like
`KotlinDeclarationProvider` extend this interface.
- `KotlinComposableProviderMerger` provides a unified interface for
provider mergers.
^KT-61791
- 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
- Composite declaration providers and declaration provider mergers are
extremely similar to the composite package providers and (newly to be
implemented) package provider mergers. This commit extracts the common
parts into a `KotlinCompositeProviderFactory`.
^KT-61791
- `getPackage` can also benefit from a combined index access.
- Care has to be taken with allowed/disallowed `kotlin` packages. Since
we're not delegating to individual symbol providers after the index
access, `allowKotlinPackage` has to be taken into account in the
combined symbol provider explicitly.
^KT-61791 fixed
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
- The function is mostly for convenience, but scope providers will be
able to optimize this scope if needed (similar to how combined
declared member scopes are already optimized).
- `getCombinedMemberScope` will be used by `KDocReferenceResolver`.
^KT-61900
- 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
Anonymous functions (lambdas) are not allowed as annotation arguments.
However, because it is still possible to parse code written this way, it
must be handled without exception. So ignore these expressions when
processing annotation arguments.
#KT-59565 Fixed
References inside LC apis are build over `ClsJavaCodeReferenceElement`,
which simplifies resolve by providing precalculated data.
When refactorings or quick fixes do on the fly resolve,
giving only text and LC context,
such precalculated data is not available and normal resolve starts.
In order for this resolve to work correctly,
LC should provide available declarations
Corresponding test in monorepo: `KotlinSymbolOnAirResolveTest`
^ KT-62440 fixed
Dmitrii Gridin