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
Mostly because of type aliases and coroutines related changes
The reason why not just +1 is to avoid clashes between 1.0.x and 1.1
in cases when version must be increased in both branches
This reverts commit 28e33aaf56.
Reverting is necessary because this change leads to complicated
exceptions, while it's usefulness is not that obvious.
#EA-82372 Fixed
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
- allowShortAnnotations is true only for IN_ANNOTATION_LIST
- when starting parsing of annotation list we can't come to modifier list
(see the only usage of IN_ANNOTATION_LIST)
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
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
Mikhail Glukhikh