When an annotation parameter has a different name than "value" or there is more than one annotation parameter we need to specify annotation parameter names explicitly in generated Java source code.
Fix using classes as annotation parameters in generated classes
Add settings for a more fine-grained control over commonizer features
that will be added in the future
Add setting and KGP flag for optimistic number commonization
KT-51011
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.
Dmitriy Dolovov