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
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
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
The previous implementation had issues with
locks, publication and performance
Also, this change fixed a problem with mixed cycle inheritance
^KT-56550
^KTIJ-25430 Fixed
^KTIJ-23520 Fixed
^KT-57623 Fixed
^KTIJ-25372 Fixed
^KT-58357 Fixed
This is needed for signature tests to work with the same golden data
on both K1 and K2, since sometimes K1 and K2 produce IR with different
order of declarations and supertypes.
Only Fir2IrJvmResultsConverter respected
the IGNORE_FIR2IR_EXCEPTIONS_IF_FIR_CONTAINS_ERRORS test directive.
Fir2IrJsResultConverter didn't.
This is fixed here.
Previously, updateTypeInBuilderInference was calling
updateTypeFromSmartcast to actually perform type update in
implicit receiver after stub types was inferred
Such action results in creation of following FIR:
FirSmartCastExpression(
original=FQAE(FirImplicitThisReference, typeRef=R|Inv<Stub>|)
typeRef=R|Inv<String>|
)
in receiver position during completion of calls
However, it wasn't the case in general situation due to
action of FirStubTypeTransformer, which, in turn visits and updates
type ref inside original expression, but only if there was at
least one call (that was completed) using that implicit receiver
As after such type update updateTypeFromSmartcast function does
nothing
Yet in situation, when there was only partially resolved calls
referencing that implicit receiver we actually create smart-cast
expression and don't update type
The change just removes usage of updateTypeFromSmartcast and
replaces is with direct type update
We still mutate state of implicit receiver, potentially
improperly, it should be addressed in future
^KT-54708
^KT-58365 Fixed
Mikhail Glukhikh