Before this commit old type parameters were inserted into new descriptor,
and that broke a simple contract: desc.child.getContainingDeclaration() == desc.
We use `doSubstitute` here because it does exactly what we need:
1. creates full copy of descriptor
2. copies method's type parameters (with new containing declaration) and properly substitute to them in value parameters, return type and etc.
But we had to customize `doSubstitute`: add some parameters like `newReturnType`
NOTE: Strange testData change.
(Mutable)List<in T!>! after substitution becomes MutableList<in T!>..List<*>?.
But it's not wrong because List<in T> behaves exactly as List<*>, and the same happens when substituing Java class scope:
public class A<E> {
<T> void foo(List<? super T> x) {}
}
Kotlin:
A.foo(), type of first value parameter --- (Mutable)List<in T!>
A<String>().foo(), type of first value parameter --- MutableList<in T!>..List<*>?
It's needed because new parameter owner is not created while enhacing types
(It was containing declaration of old value parameter that is wrong)
Also simplified SignatureParts' logic: `replaceType` is always an identity function
It's needed to enhace types when loading descriptors via reflection.
Also get rid of `enhanceSignatures` method in ExternalSignatureResolver as enhancement does not use external signature at all
Users' Java code will not break in common cases (when passing functions to
Kotlin), and deprecation warnings will be reported.
Provide an inspection with a quick fix which allows to replace deprecated
function class usages to the new classes. Include this fix to the "code
cleanup" action
Add a file in package 'kotlin.jvm.functions' to the project and replace
explicit imports of functions 'kotlin.Function{n}' to two imports 'kotlin.*'
and 'kotlin.jvm.functions.*', so that the codebase can be compiled both by the
old and by the new compiler
External annotations will be re-enabled in the IDE later.
This fixes LazyJavaAnnotations which was breaking the contract of Annotations:
findAnnotation(FqName) was looking for external annotations, while iterator()
did not. This resulted in some inconsistencies in the compiler and IDE tests.
The other way, i.e. making iterator() look up external annotations, would have
been too costly for the compiler and with no clear benefit at the moment.
Denis Zharkov