A side effect of KotlinClassFileDecompiler#KotlinDecompiledFileViewProvider@factory
that multifile java classes like FilesKt__FilePathComponentsKt.class
becomes not visible with Kotlin plugin as file
jar://..../kotlin-stdlib.jar!/kotlin/io/FilesKt__FilePathComponentsKt.class
is considered as Kotlin internal compiled file and therefore no PsiFile
for this virtualFile
#KTIJ-912
Merge-request: KT-MR-8146
Merged-by: Vladimir Dolzhenko <Vladimir.Dolzhenko@jetbrains.com>
- LL FIR didn't report a `RECURSIVE_TYPEALIAS_EXPANSION` error on `F2`
in `recursive.fir.kt`. While the resolver correctly associates `F2`
with a cyclic error supertype in the supertype computation session,
that error supertype was never assigned to `F2`.
- Why? `F2`'s supertype is a function type, so the supertype's
`classLikeDeclaration` in `collect` is `Function1`, which has no
containing file. Thus, the `Function1` was simply skipped, without
adding `F2` to the designators to which supertypes are later applied
via `apply`.
- The fix takes supertypes without containing files into account by
crawling their type arguments, which possibly leads the collector to
further designations, such as `F2`, which is reachable via the
function type's type arguments.
^KT-55339 fixed
ensure fir annotations are included in FirDanglingModifierList and resolved,
dedicated DanglingTopLevelModifierListStructureElement exists for top
level lists only, class level lists are processed by containing structure
element
k1 would suggest `get` as well
but with current fir structure with fake desugaring
get is moved to the separate fake psi which doesn't exist
thus the problem is ignored for now
^ KTIJ-24025
`candidateSymbol` has any reasonable meaning only for references with
not completed candidate, so this property is moved from FirNamedReference
to new node FirNamedReferenceWithCandidateSymbol, which has real
implementation only in :resolve module (`FirNamedReferenceWithCandidate`)
Depending on the execution, some accesses to lock could cause NPE.
The best solution we've found so far is to make lock volatile, so that
reads between lock and value are consistent between threads.
It requires further work to determine if we can have one volatile field.
When the other thread has already computed the value and cleared the
lock, the other thread could still enter the computeValueWithoutLock()
and see lock == null
Vladimir Dolzhenko