StubBasedBuiltInsSymbolProvider does not work for now for common modules (KT-61757)
but compiler builtins provider `FirBuiltinSymbolProvider` works.
Also, stub-based symbol providers should not be used in standalone mode.
Testdata from standalone is updated because of the difference
in property accessors (KT-62449) between stub and compiler builtin symbol providers.
Additionally, this commit fixes the behavior of `KotlinStaticPsiDeclarationFromBinaryModuleProvider`.
As compiler builtin declarations have no PSI attached,
`KotlinStaticPsiDeclarationFromBinaryModuleProvider` is used to get PSI
from `DecompiledPsiDeclarationProvider.findPsi`.
`DecompiledPsiDeclarationProvider` is only used in UAST standalone mode.
- 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
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
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
When it comes to finding regular class (of `PsiClass`) from the given
`ClassId`, we've reinvented the wheel in a worse way. `JavaFileManager`
is there to find `PsiClass`, and we already build/populate index for
that while initializing AA standalone mode's own project environment.
We can simply load that manager and send a query, that's it.
However, our efforts so far on binary PSI declaration providers are not
entirely useless. `JavaFileManager` can't handle top-level declarations
and search for all callables/classes in a given package in general. So,
we can still use existing logic for non-ClassId queries. We just need to
cache the intermediate results: fq name to `VirtualFile`s.
To fully utilize the aforementioned cache, we also need to cache an
instance of `KotlinPsiDeclarationProvider`.
Combing these three ideas, now running K2 UAST on a very large module is
"on par", e.g.,
K1:
//tools/adt/idea/android:intellij.android.core_lint_test PASSED in 112.8s
Stats over 7 runs: max = 112.8s, min = 104.3s, avg = 107.9s, dev = 3.6s
K2 (before):
//tools/adt/idea/android:intellij.android.core_lint_test PASSED in 303.0s
Stats over 7 runs: max = 303.0s, min = 286.8s, avg = 294.4s, dev = 5.0s
K2 (after):
//tools/adt/idea/android:intellij.android.core_lint_test PASSED in 112.8s
Stats over 7 runs: max = 112.8s, min = 105.7s, avg = 108.9s, dev = 2.4s
- 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
Adding these dependencies to the `api` configuration pollutes classpath for each dependant modules even if it doesn't need them. Instead, the dependencies should be declared more granularly if they're required
#KTI-1349 In Progress
It is true that for vararg parameter `arrayElementType` always have to
be not null, but it required resolution to TYPES phase. But in case of
the error type, the type reference is treated as resolved, so we are not
obligatory to resolve such reference to TYPES, because we already have
the resolved type.
So we can make the rule of KtFirValueParameterSymbol#returnType less
strict, and varargElementType will effectively do the same as
lazy resolve + arrayElementType
^KT-61422 Fixed
- `KtFirAnalysisSession` does not need to depend on project out-of-block
and project root modification trackers anymore, as its underlying
use-site session determines validity. To ensure that use-site sessions
are invalidated in SLC equality tests, modification events also need
to be published.
It is abstract if it has abstract member.
It is final if it doesn't have enum entries that need subclass.
Otherwise, it is open (i.e., no modifier)
^KT-57567 Fixed
...because it can be null if an anonymous object is returned as a value
of reified inline function, which isn't materialized as LC element.
^KT-59537 Fixed
- Due to the fixes for KTIJ-23584, when calling the UAST conversion
`convertDeclarationOrElement` from `BaseKotlinConverter` (intellij
project) for an SLC/ULC property, `convertDeclaration` failed because
the declaration is "special". This caused `convertPsiElement` to be
tried instead, which also returned `null`, causing the "failed to
convert element" exception described in KTIJ-25335.
- In parallel to the solution for KTIJ-23584, which fixed the special
names issue for functions, this commit skips UAST field generation for
properties with special names.
^KTIJ-25335 fixed
^KTIJ-24121 fixed
Avoid expensive calls to `navigationElement` for methods
that cannot be getters/setters and would be filtered later.
Repeat partly naming generation strategy.
Merge-request: KT-MR-10689
Merged-by: Anna Kozlova <Anna.Kozlova@jetbrains.com>
Marco Pennekamp