ConeAttributes can have some non-stable info, so we shouldn't render it
Also reduce resolve from IMPLICIT_TYPES_BODY_RESOLVE to TYPES where it is possible
^KT-58141 Fixed
Original AbstractFirSpecificAnnotationResolveTransformer can jump
to other classes and resolve them outside
our transformers, so it leads to
problems with locks and lazy bodies
^KT-56543
We cannot do it inplace now as we do not have a lock to do
it under after analysis started to use declaration-level lock
This part is mostly covered by the plugin tests
(which failed after the previous commit)
^KT-56543
The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
Enum entries can be used as types in Kotlin (even it's a compilation error)
To use the classifier as a type, we need to find if it's hidden or not.
The deprecations for classes are calculated on COMPILER_REQUIRED_ANNOTATION phase, and that's okay as it goes before the TYPES phase.
For enum entries, the deprecations are calculated on TYPES phase which goes on TYPES phase.
This is incorrect as we cannot jump from lower phase to upper phase
The hack ignores such deprecation search for enum entires.
Test: org.jetbrains.kotlin.analysis.low.level.api.fir.diagnostic.compiler.based.LLFirPreresolvedReversedDiagnosticCompilerFE10TestDataTestGenerated.Tests.testEnumEntryAsType
^KT-57648
^KT-56543
fix checking for intersection types in CheckIncompatibleTypeVariableUpperBounds
we need this resolve, because getEmptyIntersectionTypeKind under
the hood uses org.jetbrains.kotlin.resolve.checkers.EmptyIntersectionTypeChecker.computeEmptyIntersectionEmptiness
which uses computeByHavingCommonSubtype where we have
isFinalClassConstructor() call, so we need to resolve to STATUS phase
to get the correct modality
^KT-56543
In a lot of cases, when we want to process the
declaration in scope, it should be resolved to at least TYPES phase.
To avoid doing it manually in all our variety of scopes, we do it when the scope it created.
It was implicitly working manually before as lazy resolve did a lot of extra work
on resolving a declaration it was not supposed to resolve.
Now it's not the case, and we have to explicitly resolve all the declarations we need.
^KT-56543
Co-authored-by: Ilya Kirillov <ilya.kirillov@jetbrains.com>
We can't reduce resolve to COMPILER_REQUIRED_ANNOTATIONS phase for
annotations with arguments, because currently they don't have
argument mapping
```stracktrace
org.jetbrains.kotlin.utils.KotlinExceptionWithAttachments: By now the annotations argument mapping should have been resolved
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.mapAnnotationParameters(firAnnotationUtils.kt:137)
at org.jetbrains.kotlin.analysis.api.fir.FirUtilsKt.toKtAnnotationApplication(FirUtils.kt:79)
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.annotationsByClassId(firAnnotationUtils.kt:60)
at org.jetbrains.kotlin.analysis.api.fir.annotations.FirAnnotationUtilsKt.annotationsByClassId$default(firAnnotationUtils.kt:46)
```
^KT-57424 Fixed
Some of our light classes have no correct parent (KT-56882),
so I temporarily disabled
AbstractSymbolLightClassesParentingTestBase for such cases
(previously decompiled light classes were not tested at all)
^KT-56613
^KT-56882
Example:
```stacktrace
Caused by: java.lang.ArrayIndexOutOfBoundsException: Index 32 out of bounds for length 17
at com.intellij.util.containers.RefHashMap$MyMap.rehash(RefHashMap.java:85)
at it.unimi.dsi.fastutil.objects.Object2ObjectOpenHashMap.insert(Object2ObjectOpenHashMap.java:251)
at it.unimi.dsi.fastutil.objects.Object2ObjectOpenHashMap.put(Object2ObjectOpenHashMap.java:259)
at com.intellij.util.containers.RefHashMap.putKey(RefHashMap.java:160)
at com.intellij.util.containers.RefKeyRefValueHashMap.put(RefKeyRefValueHashMap.java:55)
at org.jetbrains.kotlin.analysis.api.fir.KtSymbolByFirBuilder$FunctionLikeSymbolBuilder.buildFunctionSymbol(KtSymbolByFirBuilder.kt:727)
at org.jetbrains.kotlin.analysis.api.fir.scopes.FirScopeUtilsKt$getCallableSymbols$1$1$1$1.invoke(firScopeUtils.kt:25)
at org.jetbrains.kotlin.analysis.api.fir.scopes.FirScopeUtilsKt$getCallableSymbols$1$1$1$1.invoke(firScopeUtils.kt:24)
at org.jetbrains.kotlin.fir.scopes.impl.FirClassDeclaredMemberScopeImpl.processFunctionsByName(FirClassDeclaredMemberScope.kt:103)
```
^KTIJ-22749
Dmitrii Gridin