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
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
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).
Previously IC state was stored in System properties. As result parallel
compilation might cause incorrect state of IC, what led to corruption
of kotlin_module files. Now IC state is stored via CompilerArguments
and CompilerConfiguration
#KT-46038 Fixed
The temporary solution for KT-50546.
The complete solution requires the understanding,
whether a cross-module symbol redeclaration is a valid case or not.
If the case is valid, the linker symbol table logic must be reworked.
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
Previously in 3fb1096c18 we've implemented
dumping the IR after each phase when running JS IR box tests.
However, because those dumps are saved to a temporary directory,
they can be lost in case we never make it to
`jsArtifactsHandlersStep` where files from that temporary
directory were copied to the `build/out` directory.
This could happen if, for example, the compiler crashed.
In that case, having IR dumps is even more useful, as they can help
investigate the crash.
Here we make `JsArtifactsDumpHandler` an `AfterAnalysisChecker` so that
it runs no matter what.
Dmitry Petrov