It helps to get rid of semantics duplicating and fixes known bugs
- SOE in OnlyAbstractMethodFinder.find
- type enhancement for SAM constructors
#KT-11287 Fixed
#KT-11322 Fixed
EA-77989 Fixed
Fake overrides are still created for java static with non-empty overriddenDescriptors
Add tests for inheriting visibility for java static members
Add test: check that java static declarations that shadow deprecated declarations should not be deprecated
Add test for corner case where "overriding" java static constant led to incorrect type in inheritor
Fix test data for existing tests
non-accessible in the current context, it is a compiler error.
Otherwise we might generate a CHECKCAST instruction that causes IAE at run-time.
Here we are somewhat less permissive then Java
(see inaccessibleType.kt in diagnostics tests).
Instead of erasing descriptors with conflicting substitution,
use invariant CapturedType(<projection>) as replacement for type parameter
within default member scope.
After substitution leave such types 'as is' everywhere except return types,
use common approximation for them.
#KT-9294 In Progress
#KT-5411 Fixed
#KT-8647 Fixed
#KT-9462 Fixed
#KT-9893 Fixed
#KT-7581 Fixed
#KT-7296 In Progress
Before this change they could only negatively affect on result
Now they may force success result
Also refine overridavility condition for java fields:
two java fields having the same name are seen as overrides even
if they have different type
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.
- base class method wins against a (default) interface method,
so an abstract base class method should always be implemented
in a derived class;
- interface methods clash regardless of abstract/default
with possibly undefined behavior at run-time,
so a class or interface should always define its own method
for methods inherited from multiple interfaces and not from base class;
- meaningful diagnostics for class inheriting conflicting JVM signatures.
Since no override will happen under Java 8 rules,
ACCIDENTAL_OVERRIDE is misleading for this case;
- update testData.
Denis Zharkov