- `testConflictingOverloadsAtTopLevel` is currently disabled in FIR
because it fails with a mismatch between diagnostics from the file and
the individual elements. It will be enabled in the next commit.
^KT-62899
The existing reference shortener does not use import alias when it
shortens a symbol. Instead, it adds a new import directive for the
symbol that is already imported. This commit updates reference shortener
to let it reuse the existing import alias rather than adding a new one:
1. When shortening a symbol, check whether the symbol is already
imported.
2. If it is already imported by an import alias, keep the symbol
reference expression and the import alias as a string together in
`ShortenCommand`.
The actual PSI update (shortening) based on the ShortenCommand is done
by IntelliJ.
^KTIJ-27205
This is required for some checks on call site, and it seems that
this symbol can cover all cases.
One of the examples why this API was introduced is a request to
distinguish which vararg parameter is missed in arguments
of an annotation call from symbol light classes
^KT-62560
^KTIJ-27522 Fixed
It's the only reasonable behavior for this API in it's current shape
(when it returns a list of declarations)
It's a common mistake to take only Compatible from
expectActualMatchingMap. The problem will be gone after I fix KT-62590
Motivation to fix this bug, is because it will be easier for me to split
expect-actual matcher-checker-monster thing KT-62590
Review: https://jetbrains.team/p/kt/reviews/12750/timeline
This class should contain 'global' settings for reference shortening;
ATM it only contains the `removeThis` flag
In the future this setting might be merged together with
`ShortenStrategy` to be computed on per-element basis
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62957 fixed
We should not expect builtins to be always available as they are taken from indecies.
For K1 and FIR Standalone implementations, the builtins are always available.
^KT-62010 fixed
As of now, this implementation is not supposed to be used at all
If (for some reason) it becomes relevant again, please refer
to the 7fd441f1 commit which contained a FE10 implementation
of this service (copied from the old FE10 implementation of
import optimizer)
We don't plan to seriously support the FE10 implementation of
`KtImportsOptimizer` service, since it's not going to be used in IDE
(it has its own old version of import optimization logic)
- This adds KDoc reference resolution tests for callables in nested and
inner classes, overloaded functions, and private callables.
- Private declarations are visible in KDoc from outside their containing
classes. This is in line with K1 KDoc behavior.
^KTIJ-22324
`FirSafeCallExpression` does not implement `FirResolvable`, so we need
to unwrap it to correctly resolve calls like `foo?.bar()` when `bar` is
a lambda with receiver parameter or a functional type property
^KTIJ-27434 Fixed
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>
- 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
- 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>
FIR implementation already does not have this check in
`createContextDependentCopy`, because it's called not
inside `analyze` call, but before it (see
`analyzeInDependedAnalysisSession`)
^KT-62139 Fixed
- An enum entry's body is an initializer with members only accessible
within that body. Because users of the Analysis API might want to
analyze the members of the enum entry initializer, we expose this
initializer via `KtEnumEntrySymbol`. The initializer only exists if
the enum entry has a body.
- We already have some usages of the initializer inside symbol light
classes, which generate a light class for each enum entry, which
includes the enum entry's hidden members.
- To hide the implementation detail that initializers are anonymous
objects, `KtEnumEntryInitializerSymbol` is simply a
`KtSymbolWithMembers`.
- The advantage of making it a `KtSymbolWithMembers`, instead of
providing a custom way to get a member scope, is that we can pass
around the initializer easily, e.g. in `KtEnumEntrySymbolRenderer`.
- We implement `KtEnumEntryInitializerSymbol` directly as a
`KtFirAnonymousObjectSymbol` without a wrapper. This has a few
advantages:
1. We can directly benefit from the anonymous object symbol being a
`KtSymbolWithMembers`, so we don't have to handle enum entry
initializers specially in e.g. `KtFirScopeProvider`.
2. We don't have to implement a new symbol restoration mechanism for
the initializer.
3. This implementation matches the actual FIR tree structure (with a
simplification that the connecting anonymous object expression
between the enum entry and the initializing anonymous object is
omitted).
^KT-61425 fixed
After the fix for the KT-60904 issue (c963eadb),
there are unnamed declarations created even for
the unused variables in destructuring declarations
Because of this, we can actually align testData
for K1 and K2. It seems like KT-59504 is no
longer relevant and can be marked as obsolete
because of the KT-60904 fix
^KTIJ-26959 Fixed
Marco Pennekamp