When there is unsuccessful (e.g invisible) result of one kind (static/non-static)
and there is a successful candidate for another kind, choose the latter one.
Note, that we have to postpone commiting trace until we choose one of the results,
otherwise errors of unsuccessful results are reported
TODO: Maybe it makes sense to report all results when all of them are
unsuccessful (NONE_APPLICABLE or something like this)
#KT-16278 Fixed
Get rid of trace & reportOn parameters of
createReflectionTypeForCallableDescriptor: move the two checks that required
them to DoubleColonExpressionResolver and combine with other checks into a
single function that checks the validity of the referenced symbol. This also
makes these checks reported only once when invalid expressions are passed as
function arguments (previously they were also reported from
getResolvedCallableReferenceShapeType).
Also inline getReflectionTypeForCandidateDescriptor after this, and refactor
its usages
In the expression "Runnable::run" we were resolving the left-hand side to the
SAM constructor of Runnable. Now we detect this situation, ignore the result of
such resolution, and continue resolving the LHS as a type
Reuse it in the main type-checking path in DoubleColonExpressionResolver, as
well as in ArgumentTypeResolver which handles the case when a callable
reference appears as an argument to another call
Type of '::foo' for a function foo in a class A should be KFunction0<Unit>, not
KFunction1<A, Unit>. Continue to report an error in this case, to be maybe
supported in the future
- locals win
- unary calls to plus/minus are not supported in favor of unaryPlus/unaryMinus
- unqualified nested classes are temporarily reported as unresolved
- function without receiver win against extension function
- explicit import win against star import
This syntax is reserved to be likely used in the future as a shorthand for
"this::foo" where the resulting expression doesn't take the receiver as a
parameter but has "this" already bound to it
Resolve callable references taking into account expected callable types.
This affects call resolution procedure (resolve 'foo' in for 'foo(::bar)') similar to the approach used for function literals:
* During "shape arguments" phase of call resolution, callable references are resolved in independent context without expected type. If the callable reference is ambiguous, its shape type is a function placeholder type without parameter types and return type information. Otherwise, it is a reflection type for the resolved function or property. Upper-level call is resolved without taking into account ambiguous callable references.
* During "complete call" phase of call resolution, resolve callable reference arguments to actual descriptors (if possible), and update constraint system for the given call accordingly.
#KT-6982 Fixed
#KT-5780 Fixed
Sometimes it's allowed to parse "annotation" unescaped even if other annotations must be escaped.
A set of annotations and their options tests.
A swarm of existing tests fixed (mostly kotlin.annotation.annotation() added to txt-files).
STUB_VERSION increased. Some quick fixes slightly changed.
Get rid of all classes except kotlin.reflect.KFunction, which will be used to
represent all kinds of simple functions.
Lots of changes to test data are related to the fact that KFunction is not an
extension function (as opposed to KMemberFunction and KExtensionFunction who
were) and so a member or an extension function reference now requires all
arguments be passed to it in the parentheses, including receivers. This is
probably temporary until we support calling any function both as a free
function and as an extension. In JS, functions and extension functions are not
interchangeable, so tests on this behavior are removed until this is supported
Without this, the unrelated type specified on the LHS of a property reference
literal was considered to be an extension receiver of the candidate, and the
resolution was erroneously successul. This is only reproducible for properties,
because if we're trying to resolve an extension, we consider all properties
from the scope, even non-extensions, because there may be a property of an
extension-functional type (T.() -> R). (We don't do this for functions.)
#KT-7430 Fixed
#KT-7945 Fixed
For example,
KMemberFunction2<T, P1, P2, R> : KMemberFunction<T, R>
So for this inheritance the heuristic that was present ("take the last K type
parameters of the subclass, and substitute for K parameters of the superclass")
was wrong. The new heuristic for this case is: take type parameters with the
same names.
Also don't store "parameters" in a lazy value, since it's easy to compute and
it's computed practically every time anyway
