Following the TODO in CallableReferencesResolutionUtils.kt, delete the
suspicious scope and use the new resolution process with the qualifier which
was obtained after the resolution of LHS. However, by default the tower
resolution algorithm also considers each qualifier as a class value as well,
which would be wrong here because resolution of LHS as a "value" happens
earlier in DoubleColonExpressionResolver and with slightly different rules. To
avoid that, do not mix in the "explicit receiver" scope tower processor when
creating processors for callable reference resolution.
Also delete unused functions and classes related to deleted scope, refactor
Scopes.kt
#KT-8596 Fixed
Try resolving the LHS only when it looks (PSI-wise) like it could represent a
type element. This, for example, allows "illegal selector" error to be reported
on weird expressions like '""?.""::class'.
Also remove expression text from the "illegal selector" diagnostic, it's not
needed and can screw up the error message if the text is too big
It's needed when declarations are parsed as a part of previous expression
(see tests)
Currently we apply this kind of recovery in a conservative way,
only when declaration starts at the next line, and while
the condition could be relaxed, there's no need to do this
#KT-4948 Fixed
#KT-7118 Fixed
Otherwise linenumber for previous instruction will be used in debugger. That can lead to error stepping
because it might be line that isn't reachable on current iteration.
#KT-13059 Fixed
Do not treat var as alive just because current instruction belongs to an item range
in local variables table, but the item has different sort of type
As liveness analysis is mostly used in coroutines spilling,
not applying this change may lead that to problems on Android (see tests)
If property name is parsed on the next line and declaration is invalid
(no receiver/type/initializer), treat that name as it does not belong to property
#KT-12987 In Progress
Previously the code was operating under the assumption that if the
implementation of some function (both the implementation and the function come
from supertypes) does not have a proper return type (the one which is a subtype
of return type of all declarations of this function in the supertypes), then
there's necessarily at least one abstract declaration of the function, such
that the implementation's return type is not a subtype of the return type of
that declaration. The assertion makes sense when the hierarchy above the
current class does not have any errors: we should report at least one function
as being "not implemented" in the current class.
However, as demonstrated by the test case, if there's an error already in the
supertypes with regard to overridability of members, this assertion may be
wrong. Reporting the "not implemented" error in such case is in fact not
necessary because of the already existing error ("return type mismatch" in the
test) in the supertypes
#KT-12482 Fixed
At first we try to resolve 'handleResult' just as last expression
in a lambda is first argument, then if results are unsuccessful
try resolve 'handleResult' with fake Unit expression
#KT-12969 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
The main change is in
NewResolutionOldInference.ResolutionKind.CallableReference, where
createVariableProcessor creates a processor which no longer lists objects
#KT-12322 Fixed
There are two main changes here:
- In CallCompleter, there was a bug: we assumed that the return type of a
candidate must be a subtype of the expected type and were adding a
corresponding constraint to the system. However, this is not true for
callable references where the type of the expression is KFunctionN<...> and
the return type of the candidate must be a subtype of the _last generic
argument_ of the functional type.
- In CandidateResolver, we use a more correct (although still not precise)
heuristic to determine if a candidate fits based on the non-substituted type
of the callable reference expression which it would produce.
This can be further improved, see TODOs in CallCompleter. Also this does not
influence resolution of callable references being passed as arguments to
generic calls (that happens in GenericCandidateResolver)
#KT-10968 Fixed
#KT-11075 Fixed
#KT-12286 Fixed
#KT-12963 Open
#KT-12964 Open
See 4a533168d9 for the original change which
introduced the problem
Note that the added test case _was not failing_ before the change. It's added
because there were no tests on multi-file class behavior in light classes mode
at all. The actual repro for the problem is difficult to make a test from
#KT-12755 Fixed
- remove Future from resovler since the idea need additional considerations
- simplify script contents interface
-extend script dependencies with additional javaHome property
- return Future from resovler
- pack script contents data to a separate interface
-extend script dependencies with additional scripts property
- minor renames and moves
Do not generate stubs if there is no special bridge in the current class
- there are already Kotlin super class in hierarchy
- special bridge has the same signature as method itself
#KT-11915 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
Alexander Udalov