if property doesn't specify explicit type,
property's return type would be calculated by provided initializer
^KT-62588 fixed
Merge-request: KT-MR-12564
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
We should process generated property as a part of the primary constructor.
This was already implemented in 8387ea8a, but some parts were missed.
ClassDiagnosticRetriever:
* dropped relation to properties generated from constructor parameters
as they should belong to the primary constructor only
* accurate logic to fully visit an implicit primary constructor to be
able to process nested declarations (e.g., inside a super type call)
SingleNonLocalDeclarationDiagnosticRetriever:
* add relation to generated properties as now they fully belong to
the constructor
FileElementFactory:
* dropped explicit resolution of generated properties from a constructor
* added explicit resolution of generated enum members for consistency.
Effectively, this is not required because we don't have compiler
checkers for such generated enum member declarations
ClassDeclarationStructureElement:
* do not collect mapping for generated properties from constructor
* explicitly declare that we should process only ClassDelegationField
^KT-62437 Fixed
Before the code fragment analysis was extracted to the separate module,
it was impossible to modify the symbol provider, so a conflict resolver
was patched instead. The solution was not complete, though, as it only
covered call resolution ambiguities. The compiler sometime calls a
symbol provider directly, like it's done in 'BuiltinSymbolsBase'.
Relevant tests are in the IntelliJ project (see singleBreakpoint/
conflictingStdlib.kt).
^KTIJ-27329 Fixed
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
Roman Efremov