fir which is retrieved by LL symbol providers based on stubs,
receives builtin origin when found in kotlin_builtins
pure compiler providers found the same fir declarations in stdlib
and thus receive Library origin
to avoid splitting the testdata, let's ignore the difference
during java annotations mapping in IDE, kotlin classes are not available,
thus FirFromMissingDependenciesNamedReference is created
Corresponding test in IJ repo:
K2HighlightingMetaInfoTestGenerated.Uncategorized#testJavaTypes
this gives the following benefits:
1. no protobuf in memory, all data is already present in stubs
2. given that symbol provider for libraries is already stub based,
we can get rid of complicated code to find source psi by deserialized fir
3. it's also possible to reduce number of index access,
when fir is requested for given ktElement
The fix deals with the situation where a virtual function potentially from
the external world (because of the receiver) returns a final type (if it isn't final,
then it's conservatively assumed that no devirtualization could be done on it).
#KT-57791 Fixed
Basically, the test checks that adding Enum.entries feature doesn't
break the existing code where it clashes with the user-defined "entries"
declaration; it's better to have a black-box test to be sure
that the compiler doesn't invoke something different at runtime
The test covers KT-53153 and KT-56587
Merge-request: KT-MR-9798
Merged-by: Michail Zarečenskij <Mikhail.Zarechenskiy@jetbrains.com>
We should try to find supe type refs in a session firstly, otherwise
we can try to access by getResolvedSuperTypeRefsForOutOfSessionDeclaration
^KT-56550
We can omit this step in LL FIR because, according to the contract,
an outer class must be resolved before nested class
Also, it drops unsafe access to superTypeRefs from FIR transformer
^KT-56550
It's an unfortunate clash between introduction of KotlinPluginLifecycle
and changes in 'deprecationDiagnostics.kt'. It used 'afterEvaluate',
but with KotlinPluginLifecycle later stages are effectively invoked
in multiple nested afterEvaluate, making them invisible for single
afterEvaluate.
Specifically in this case, configuration of metadata compilations for
intermediate source sets is executed in 'FinaliseCompilations' stage,
which is simply not executed by the time checker runs in its single
afterEvaluate.
The fix is trivial -- wrap diagnostic checks runs into launchInStage
^KT-58470 Fixed
We must resolve a non-local declaration before access
if we want to jump from local to it to avoid possible problems
with parallel resolution
^KT-56550
Bogdan Mukvich