Backend requires annotation constructors to be fully resolved for the
'IrConst' default value lowering. However, in the IDE there is usually
no need in complete annotation class resolution.
^KTIJ-27061 Fixed
In the Kotlin compiler project, built-in classes are resolved to source
declarations. It's not an issue for usual file analysis in the IDE, as
referenced built-ins are analyzed on demand.
Fir2ir, however, fetches built-in classes at once without checking its
resolution state, breaking code compilation in the IDE.
^KTIJ-27061 Fixed
`property.backingField != null` is too soft condition because currently
each property has a backing field. We should trigger the full body
resolution only in the case of an implicit type on the property or on
the backing field
^KT-61991 Fixed
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
This fixes the difference at least in the IR text test
testFakeOverridesForJavaNonStaticMembers. There's no fake override
created anymore for `packagePrivateMethod` in Test2.
#KT-61366 Fixed
...without `isTopLevelOrInsideClass` property. Behavior stays the same,
because in fact we require all `expect` member declarations to be non-private
except constructors and property setter.
Enhance already existing test.
^KT-59899
We don't want any `expect` function to have body. So we're sure no
new false-positive reports are introduced because of removal of
`isTopLevelOrInsideClass` condition.
^KT-59899 Fixed
...to separate methods.
After the change each diagnostic report has its own condition,
independent from others, so you don't have to keep in mind
"we're in else branch, so this is already not a FirConstructor
and also it either top-level or inside classs".
This makes changes in next commits more clear and verifiable.
`isTopLevelOrInsideClass` condition for
`getConstructorDelegationCall` is not needed, because
constructor is always inside class.
^KT-59899
For an example of an object with
an implicit primary constructor,
see `FirPsiOldFrontendDiagnosticsTestGenerated.testSingletonAndFunctionSameName`.
^KT-62005 Fixed
Merge-request: KT-MR-12242
Merged-by: Nikolay Lunyak <Nikolay.Lunyak@jetbrains.com>
Make `FirShorteningContext` correctly return symbols for type
parameters, so they are not ignored when scopes are inspected
Add additional type of `PartialOrderOfScope` - `TypeParameter`, because
otherwise it would have been classified as `Unclassified`, and that
breaks scopes comparison
Add missing type parameters to the scope of class header in
`ContextCollector`, add testdata for that
There is a bug in the compiler with type parameters leaking to nested
classes headers (KT-61959). After it's fixed, the testData with
incorrect expected shortenings/scopes should be adjusted and fixed too
^KTIJ-27050 Fixed
There is IDE quick fix which suggests to copy mismatched annotation
from `expect` to `actual` (see KTIJ-26633). It needs to find
`actual` PsiElement where to add annotation. Before previous commit, it
was easy - just get source of `Incompatibility.actualSymbol`.
After previous commit, the problem might be in value parameter, while
`actualSymbol` would contain function symbol. This is solved by adding
new field `Incompatibility.actualAnnotationTargetElement`.
`SourceElementMarker` introduced, because it's needed to be used in
abstract checker. Existing `DeclarationSymbolMarker` doesn't fit
because in next PR for this issue annotations set on types will be reported,
and types are not declarations.
^KT-60671
Pavel Kunyavskiy