After this change SAM adapters are being resolved in the same group
as members, thus their overload resolution happens simultaneously.
But in the case of overload resolution ambiguity try to filter out all
synthetic members and run the process again.
See the issue and new test for clarification
#KT-11128 In Progress
Just reporting error by call checker may be too restrictive
in case there are some extensions that can be used successfully
Solution is to annotate additional members with
@Deprecated(level=Error) + @kotlin.internal.LowPriorityInOverloadResolution
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
- First parameter should have type of K instead of Any
- Special bridge should return second parameter if a key has wrong type
- Special bridge may throw an exception if defaultValue has wrong type
#KT-13209 Fixed
- White list: can be used as common built-in declaration
- Black list: can be used only for overrides and super-calls-
- Not considered members: ones that is not in black or white list.
Such members can be used in any context, but they usages marked as deprecated
Third kind is needed to make possible use declarations added in future JDK versions.
Deprecation is necessary because they may get into black list in next Kotlin compiler version
It can be used to specify enhanced signature for standard JDK methods
without them be actually annotated
#KT-9194 In Progress
#KT-5175 In Progress
#KT-10370 In Progress
#KT-7127 In Progress
At this very short moment Kotlin supports both annotation(retention, repeatable, mustBeDocumented) and Retention / Repeatable / MustBeDocumented separately.
