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
When stdlib is represented as a source dependency (which seems to be the
case in the `kotlin` project), it will be resolved lazily for the IDE.
Same thing can happen if someone decides to "extend" the stdlib
by declaring their declaration in the `kotlin` package
In both of those cases, we need to make sure that receiver type is fully
resolved before trying to get a `coneType` from it
N.B. To make resolve tests work, I've added a separate folder
`withAllowedKotlinPackage` to the `testData`, because in the default
test setup it is not allowed to extend the `kotlin` package by user's
definitions
^KT-50728 Fixed
Mostly, it only affects FIR
It partially allows to consider several variance of constraints like
A<Int> & A<T> <: A<X_var> that are mostly brought by smart casts
^KT-49542 Fixed
^KT-50489 Relates
There are two possible scenarios, when fun interface method with inline
class parameter can be compiled.
First is when we compile fun interface itself before SAM adapter. In
that case, fun interface is lowered before we lower SAM adapter. Thus,
its method is mangled and mangling in the second time is an error.
Second is when we compile SAM adapter before the fun interface. In that
case, fun interface is not lowered, and we have to mangle the method.
The only way to distinguish there two cases I can think of is to check
whether the overridden method is already mangled, in other words, check,
whether the overridden method's suffix is doubled.
#KT-48499: Fixed
Ivan Kylchik