We should provide valid getReferenceName as it is used
in many places (e.g. from com.intellij.psi.impl.PsiImplUtil.findAnnotation)
^KT-61605 Fixed
^KT-64605 Fixed
This commit introduces dangling file modules, which may be either
code fragments or ordinary Kotlin files. As before, code fragments are
analyzed against some context element, however ordinary files only
have a context module.
Code fragments can also have a dangling file module as a contextual one,
including other code fragment. This is done to support potential usages
in completion, intentions and refactorings.
We shouldn't build expect declarations as they do not
exist. We can omit check on member declarations as we
won't request them as we skip expect classes
^KT-57536 Fixed
Multifile-class can contain not only files from the same
module, but also files from the common part.
This commit also fixes KotlinByModulesResolutionScopeProvider as
it should provide all transitive dependencies
^KT-64714 Fixed
Previously we just skipped Java sources.
The order of classes in light classes test data is changed due to
differences in implementations of `compileLibraryToJar` and `runJvmCompiler`
^KT-62892
We should use PsiLiteralExpression instead of PsiLiteral as it
is used in the Java world. Effectively, `psiLiteral` property
already has this type (as `createPsiExpression` produce `PsiExpression`),
but we missed this part before and used just PsiLiteral for our
own class
^KT-63949 Fixed
When we check Java field for constant initializer, we could
be asked to get and check the type of Kotlin's property that
is used in this Java field. But there is no guarantee that the type
resolve phase was finished and this type is available. So we just
check for `const` modifier and skip type check.
#KT-63752 Fixed
#KT-62558 Obsolete
#KT-61786 Declined
Use test compiler runner to compile JS libraries. Determine compiler
by the specified TARGET_PLATFORM. Add tests for dynamic type and
JS-specific .proto extensions.
Refactor the code for mock library compilation to make the switch
between platforms more straightforward.
KTIJ-27566
KT-63217
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.
Dmitrii Gridin