Doing so speeds up psi2ir ~2 times, and thus improves total compiler
performance by about 6-8%.
Unless JVM IR is in the mode where linking via signatures is the only
way (-Xserialize-ir, -Xklib), signatures are actually not needed at all,
SymbolTable can use the frontend representation (descriptors for FE1.0,
and hopefully FIR elements for K2) as hash table keys. The only catch is
that since other backends still need to work with signatures, all the
common IR utilities, such as irTypePredicates.kt, need to work correctly
for IR elements both with signatures and without.
Also, introduce a fallback compiler flag -Xlink-via-signatures, in case
something goes wrong, to be able to troubleshoot and workaround any
issues.
#KT-48233
It's necessary to allow a?.b += v be interpreted as a?.(b += v)
But currently FirAssignmentOperatorStatement is not FirQualifiedAccess
^KT-41034 In Progress
So, treat CHECKCASTs as { POP, Unit } sequences. If the CHECKCAST is
between suspension point and ARETURN, put check for COROUTINE_SUSPENDED
before it and return if the suspension point is suspended.
This is safe, since if the function throws CCE, it will be thrown from
the last state in state-machine and we cannot reenter the function
during resume. So, in case of CHECKCAST throwing CCE the behavior is the
same, whether we have state-machine or not.
We do not need to disable TCO in some cases, as we do for functions,
returning Unit, since in latter case suspend function, returning Unit
might appear as returning non-Unit during resumption due to missing
{ POP, Unit } sequence, which is not executed, since the function is
tail-call. However, in case of functions, returning non-Unit there is
no such concern, since we do not POP result of suspension point, but
rather, return it after CHECKCAST.
#KT-50835 Fixed
Result of calling `ExpressionCodegen.gen` was used only in two call
sites in the inliner. In all other call sites, we were doing unnecessary
work (and sometimes were even failing) by trying to construct a
KotlinType instance out from an IrType.
Note that even though the code from KT-50617 no longer fails to compile,
the underlying problem is still not solved, since the IrType for foo's
dispatch receiver is constructed incorrectly. The reason is that
SymbolTable links everything by IdSignature, which is identical for
classes with the same FQ name.
#KT-50617 Fixed
Dmitriy Novozhilov