In Kotlin subclasses of `MutableCollection<Int>`, the method
`remove(Int)` has its argument boxed, so that it wouldn't clash with the
method from `java.util.List`. So `JavaOverrideChecker` should understand
that a Java method `boolean remove(java.lang.Integer)` overrides it,
otherwise platform declaration clash was reported.
The code is adapted from `forceSingleValueParameterBoxing` in K1's
`methodSignatureMapping.kt`.
The test has been moved and adapted from diagnostic to codegen box
tests, to check correct backend execution + runtime.
#KT-62316 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)
Some of the changed data is correct, but some diagnostics are incorrect
Corner cases like having both contains(Object) and contains(String)
within implementation of Collection<String> is not supported
There was a refactoring of AbstractDiagnosticsTest in 9052ef06 which
contains bug that `setupEnvironment` for AbstractDiagnosticsTestUsingJavac
was not called, so for last year tests `UsingJavac` had no difference
with usual diagnostics tests which causes some contradictions in test data
In this commit we change value parameter type of containsAll, removeAll,
retainAll from Java collections. Originally it's Collection<?>,
we change it to Collection<T>
#KT-42340 Fixed
If property accessor rendering is disabled in a test, render annotations
on accessors as use-site-targeted, as was done with
`@setparam:`-annotations. Otherwise they were lost
Do not treat members with already changed signature as a reason
to create a hidden copy
See tests for clarification:
- There are `charAt` method in B that has different name in Kotlin - `get`,
i.e. relevant descriptor has initialSignatureDescriptor != null
- When collecting methods from supertypes, `charAt` from A is also get
transformed to `get`
- So it has effectively the same signature as B.get (already declared)
- If by an accident B.get had been declared with Kotlin signature
we would have add A.charAt (after transformation) with special flag:
HiddenToOvercomeSignatureClash (hides it from resolution)
- But here B.charAt was artificially changed to `get`, so no signature clash
actually happened
#KT-13730 Fixed
It has been done just to avoid clashes with real declarations that look
like our builtins: e.g. 'String removeAt(int index) {}' and 'String remove(int index) {}'in Java.
But synthesized members are even weaker than extensions.
Solution is just to ignore the latter declaration and treat first as effective override
of out builltin.
Mikhail Glukhikh