It's implemented as IR checker because in K2 constant expressions are
evaluated on backend. FIR diagnostic removed because isn't needed.
"annotationViaActualTypeAlias" test has no `// FIR_IDENTICAL` because
diagnostic reported on entire typealias declaration instead of its name.
This is because in IR+LightTree we have only offsets, so can't navigate
to typealias name element.
^KT-59940 Fixed
In-block modifications are applicable only for FIR declarations with
fully resolved bodies. It can happen only during implicit type and body
phases. The implicit type phase probably is not applicable for our
particular case, but we will play safe because properties have a
complicated resolution logic, so it is hard to be sure that only body
phase will be enough.
Changes inside contracts are treated as out-of-block, so we can avoid
marker from this phase. Also, all mentioned calls inside bodies resolve
the corresponding declarations to the contract phase, so we will save a
lot with this optimization.
Q: Why in-block modification can be heavy?
A: In most cases this invalidation is pretty cheap because we have all
required information inside caches. But it is possible that we can
receive an in-block modification event for PSI without a corresponding
FIR element, or it is not yet fully resolved. In this case, for example,
we will do such redundant works as a raw FIR building or KtModule search
^KT-61842 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
This is needed because in order to figure out which declarations are
visible from anonymous objects in terms of overridability (see
`FirVisibilityChecker.isVisibleForOverriding`), we need to get the
package name of that anonymous object, because there's package-private
visibility on JVM.
#KT-62017 Fixed
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
`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
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
It is incorrect because has expect and actual in same module,
which results in ACTUAL_WITHOUT_EXPECT reported in FIR.
But there is already same test
`multiplatform/incDecOperatorsInExpectClass.kt`, so there is no need
to fix and maintain test `IncDecOperatorsInExpectClass`.
^KT-60075 Fixed
The checker also checks the metadata version, which
would be handled separately. Now it would never
emmit this error for klib-based backends.
^KT-61773
^KT-61596
^KT-55809
The call-sites don't actually need to handle unresolved expressions,
they only need safe-casts to ConeClassLikeType or
ConeIntegerLiteralType.
#KT-61367
FirFile after KT-56683 has its own phases and resolution logic,
so we should have a separate API for lazy resolution for FirFile and for
the entire file
^KT-61296 Fixed
Kirill Rakhman