The issue this commit fixes occurs when we have an external interface
implemented by a Kotlin class, if that interface has methods with
varargs.
Kotlin functions expect varargs passed as arrays, but JavaScript code
may be unaware of this convention.
So, when generating a bridge for external interface method
implementaion, we insert some additional logic for extracting varargs
using the JavaScript `arguments` object.
A simplified example:
```kotlin
external interface Adder {
fun sum(vararg numbers: Int): Int
}
class AdderImpl: Adder {
override fun sum(vararg numbers: Int) = numbers.sum()
}
```
For `AdderImpl` we generate the following JS code:
```js
AdderImpl.prototype.sum_69wd7h_k$ = function (numbers) {
return sum(numbers);
};
AdderImpl.prototype.sum = function () {
var numbers = new Int32Array([].slice.call(arguments));
return this.sum_69wd7h_k$(numbers);
};
```
#KT-15223 Fixed
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
In this commit we upgrade FIR builder inference logic from
the compiler version to 1.7. FIR-based compiler now works with
"don't use builder inference" flag always ON and supports switching
the flag "use builder inference only if needed". To do it,
ContraintSystemCompleter (FIR) and KotlinConstraintSystemCompleter (FE 1.0)
are made similar with extracting some common parts into
ConstraintSystemCompletionContext.
Test status: one BB test fails after this commit (KT-49285).
Also we have a crush in DFA logic in FIR bootstrap test and somehow
questionable behavior in FIR diagnostic test. However,
two BB tests were fixed, the 3rd case from KT-49925 were also fixed.
#KT-49925 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
This big refactoring is needed to cleanup building of overrides
mappings and prevent creating redundant intersection overrides in
cases when there is no need in them:
```kotlin
interface A {
fun foo()
}
interface B {
fun foo()
}
interface C : A, B {
override fun foo()
}
```
Before this refactoring there was next override tree:
C.foo
intersection override (A.foo, B.foo)
A.foo
B.foo
Also this commit fixes special mapping of overrides in jvm scopes
for declarations which have kotlin builtins in supertypes with
special java mapping rules (collections, for example)
Otherwise the tests are flaky for some reason; stack overflow is thrown
from psi2ir sometimes. Probably it has something to do with the fact
that the JVM stack which is used by the compiler here is around the
default limit (which is 1M).
Dmitriy Novozhilov