Effectively, this commit drops cached value for j.l.Object type
This cache was introduced when types were immutable, but they
became mutable after starting reading top-level TYPE_USE annotations,
that lead to changing shared JAVA_LANG_OBJECT_CLASSIFIER_TYPE instance
#KT-20826 Fixed
If there is default qualifier with TYPE_USE closer than one with METHOD
then its nullability should be considered even when enhancing return type
#KT-20016 Fixed
- Apply default qualifiers to type arguments if they contain TYPE_USE
in applicability list
- Read TYPE_USE placed default qualifier annotations
#KT-19592 Fixed
#KT-20016 In Progress
The regression appeared after
b5a8ffaddc
when we started trying both static and member methods until
first success and when there is no successful
we were just leaving the last one (e.g. private member)
But the actual problem is that we were commiting the trace
in case of single (but incorrect) result in resolution mode of
SHAPE_FUNCTION_ARGUMENTS when we couldn't yet choose the
correct static method
Also we shouldn't choose a shape for callable reference
using only the knowledge that result is single:
it may lead to the wrong inference result
(see test with Pattern::compile)
#KT-17597 Fixed
See doNotCaptureSupertype test for clarification:
When resolving b.collect(toList()) we're building a common system with
two variables T and R.
The problem was that when introducing the constraint
C<T, Inv<T>> <: C<in String, R> we then were seeing the constraint
T <= in String, and add the constaint T=Captured(in String)
That lead to R=Inv<T>=Inv<Captured(in String)>, and after approximation
R=Inv<in String>, that is not the desirable result (Inv<String> suits here)
But the root problem was that we add captured constaint when projection was from supertype,
that seems to be wrong, and for example Java doesn't do that in the similar situation.
#KT-11259 Fixed
Inferred type of receiver of orElse is Optional<T & Any>
Generic descriptor is orElse(E!): E!
Substituted descriptor is orElse(T): T , and that is the problem.
Seems that E! => (T & Any)! gets expanded to just T or T & Any , however it should be expanded to
(T & Any) .. (T & Any)? => T & Any .. T & Any
T & Any is NotNullTypeParameter(T)
The problem is that (T & Any)? is expanded to T & Any,
that is seems to be wrong.
#KT-15236 Fixed
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
Zalim Bashorov