This cache wasn't working too well, because ConeTypes have
equals/hashCode implementations which do not account for types'
attributes (like annotations, for example).
Because of that, `String` and `@Annotated String` were considered the
same type, and the cache was remembering whichever came first.
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
`jsArguments()` is lowered into a reference of the `arguments` object.
This is useful for extracting varargs, when calling Kotlin code from
JavaScript. For a concrete example, see KT-15223.
Previously, if multiple operators with the same name were defined in
a single class, we could look up neither of them (for example, the `Int`
class defines multiple `plus` operators, one for each primitive type
referenced on the RHS).
Now we can distinguish operator functions by their RHS type when
performing operator lookup in the backend.
Fix the behavior of the common (metadata KLIB) compiler with
hierarchical project structures support as
it analyses usages of annotations from dependencies that are marked
with `@OptionalExpectations`.
The fix on the Kotlin Gradle plugin side is to add the
-Xcommon-sources=... compiler argument to those the invocations of the
compiler, just as it is done with the other compilers.
Issue #KT-49089 Verification Pending
Test: Existing IncrementalJvmCompilerRunnerTestGenerated.PureKotlin#testCompanionConstantChanged
and similar *.PureKotlin#testCompanionConstantChanged tests
Cases that necessitate the return type hack (see KT-46042) always
involve exactly two methods, exactly one of which is a fake override. It
is sufficient to mark one of them.
This is done to prevent unintentional side effects from Gradle, which
might act hostile against third-party implementations of Gradle public
API interfaces.
This is to avoid leaking the extension function defined
inside those objects to the global namespaces.
Using these extensions on the receiver outside the
noop object makes no sense.
Mikhail Glukhikh