If property accessor rendering is disabled in a test, render annotations
on accessors as use-site-targeted, as was done with
`@setparam:`-annotations. Otherwise they were lost
Note, that this change potentially has some other effects in corner cases
(like the changed test data that is rather sensible because `bar`
in the example is not effectively projected out and can be called
with nulls)
Probably, we need to consider rewriting all other isSomeType methods
in KotlinBuiltins, but now it seems to be a rather dangerous change
#KT-16424 Fixed
Prior to the 1.1.4, nullability related annotations were stored
in types that became hard to maintain at some moment and
we got rid of it (see 57b7b91444)
But enhancement for properties overrides stopped working
because there were effectively no annotations in the
resulting descriptor
#KT-19409 Fixed
#KT-19409 Fixed
Except AnnotationDescriptorImpl, which is refactored in the subsequent
commit.
Note that we no longer check the presence of parameters with the
corresponding names in the annotation class in
LazyJavaAnnotationDescriptor, this is why test data changed
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
com.typesafe.akka:akka-cluster-sharding_2.12:2.5
akka.cluster.sharding.ClusterSharding has the following methods:
public static ClusterSharding get(ActorSystem var0) {
return ClusterSharding$.MODULE$.get(var0);
}
public static Extension get(ActorSystem var0) {
return ClusterSharding$.MODULE$.get(var0);
}
NB: ClusterSharding <: Extension
None of these methods is synthetic or something, but javac allows
calls like ClusterSharding.get(null) and they get resolved
to the first method returning ClusterSharding
It seems that both javac and IntelliJ resolution algorithms filter out
such clashing declarations choosing the one that has the most
specific return type, the same idea is applied in the change
#KT-17560 Fixed
When synthetic member comes not from the receiver type itself,
but from one of its supertypes it doesn't make sense to subsitute
the member with receiver type, we should obtain relevant supertype
and use it instead.
#KT-16578 Fixed
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
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
It works only for Java methods and it's purpose is Java overridability rules emulation,
namely distinction of primitive types and their wrappers.
For example `void foo(Integer x)` should not be an override for `void foo(int x)`
#KT-11440 Fixed
#KT-11389 Fixed
Encapsulate everything that is needed in checkers into CallCheckerContext. Pass
an instance of this context instead of BasicCallResolutionContext to checkers.
Also pass an instance of the element to report errors on: this is useful
because before this, every checker had its own way of determining where should
the error be reported on. Some of them, for example, were not doing anything if
Call#calleeExpression returned null, which is wrong, see operatorCall.kt
#KT-12875 Open
Use the same component (NotFoundClasses) as in loading of compiled Kotlin
symbols.
Some tests were changed to avoid a diagnostic that is now reported when a
non-found class is encountered in a signature (e.g. staticMethod.1.java where
JDK seems to be not configured)
#KT-10493 Fixed
#KT-10820 Fixed
#KT-11368 Fixed
Load immutable flexible upper bound for 'Iterable<? super T>'
We load 'Collection<? super CharSequence>' as 'MutableCollection<in CharSequence>'
instead of 'MutableCollection<in CharSequence>..Collection<*>'
because it's obviously not typesafe to use any 'Collection<*>'
as argument for such type.
But there'se nothing bad with loading 'Iterable<? super CharSequence>'
as 'MutableIterable<*>..Collection<*>'. Same for other declarations that have
covariant mutable representation (currently Iterator, ListIterator).
Also there are useful use-cases when it's neccessary to use 'Iterable<*>'
as an argument for parameter with type 'Iterable<? super T>' (see matchers.kt test).
NB: Star-projections appear in examples because types like 'Collection<in CharSequence>'
with conflicting use-site projections are invalid in Kotlin, but they are valid in Java.
Alexander Udalov