This may be more correct in case of complex cross-module inheritance, where
overridability should be detected by structural equality of signatures instead
of referential equality of constructed descriptors (no test added because it's
not so easy to come up with an example)
To simplify migration from 1.0 to 1.1, do not allow data classes to
automatically implement abstract equals/hashCode/toString declared in
super-interfaces (KT-11306) if "-language-version 1.0" is specified
Change getAllOverriddenDescriptors contracti, now it returns
original (not substituted) descriptors without any duplicates.
First of all it's necessary in CodegenUtil.getDelegates to avoid
duplicates (see assertion there), but also it's convenient for all
other usages of this method
#KT-8154 Fixed
- change prerequisites for generating equals/hashCode/toString in a data class:
previously they were generated if the corresponding method is trivial (i.e.
it comes from kotlin.Any), now we're generating it always unless it'll cause
a JVM signature clash error (see KT-6206)
- use static KotlinBuiltIns.isXxx methods to compare types instead of checking
against descriptors loaded from certain built-ins instance, this is quicker
and more correct in environments where several built-ins are possible
- don't use isOrOverridesSynthesized, it's not relevant for
equals/hashCode/toString because functions with these names are never
synthesized
#KT-6206 Fixed
- report errors on implementing methods of Any in interfaces
- update testData
~~~
Java 8 override restrictions: interface can't implement a method of 'Any'
- update compiler sources
0. Such properties are called special because their accessor JVM name differs from usual one
1. When making call to such property, always choose special name
2. When generating Kotlin class inheriting such property generate `final bridge int size() { return this.getSize(); }`
3. If there is no `size` declaration in current class generate `bridge int getSize() { // super-call }`
Roman Elizarov