Otherwise, when completing all the unsuccessfull candiates,
resolution of each lambda-arguments starts repeatedly for each candidate
that leads to exponential time
NB: Changes in `completeArguments` are necessary because otherwise
nested lambdas will be analyzed twice:
once for the main resolved call, and then for all candidates
that again leads to exponential complexity
#KT-16672 Fixed
#KT-19457 Fixed
receiver type with modifiers or annotations should be surrounded in parentheses on rendering: '(@A R).() -> T'
This also fixes stub builder tests (which check that stubs are consistent with rendered descriptors).
(required for 'suspend' on functional types).
TYPE_REFERENCE element now has MODIFIER_LIST child, which hosts annotations and modifiers for the corresponding type reference.
Annotations and modifiers written before an extension function type are now parsed as annotations and modifiers for the functional type, not the receiver type.
So, '@Ann A.(B) -> C' was '(@Ann A).(B) -> C', and became '@Ann (A.(B) -> C)'.
NB: DSL_SCOPE_VIOLATION testData updated accordingly.
Type projection variance modifiers ('in', 'out') belong to a separate modifier list under corresponding type projection (not under a type reference).
'A<in suspend T>' is 'A<(in (suspend T))>', 'A<suspend in T>' is an error.
In stub builder, create a modifier list node to host annotations and modifiers (none so far; TODO properly serialize/deserialize types with modifiers).
There is no need to report an error in case of non-top-level
capture conversion, just don't add relevant capture type in the system instead
If system can be solved successfully without captured type, then it's just fine
(see KT-13950)
In case of contradiction TYPE_INFERENCE_PARAMETER_CONSTRAINT_ERROR is reported
#KT-13950 Fixed
Use 'expectedType' (when present) as an explicit type argument for a special construct call.
Unfortunately, this approach can't be used for elvis due to other elvis-related inference hacks.
Fixes KT-10807, KT-10811.
This also affects KT-6189: now we can infer proper type for 'if'.
If type inference for special call failed, and we found no type errors in sub-expressions,
report TYPE_INFERENCE_FAILED_ON_SPECIAL_CONSTRUCT error.
This (and the hack above) fixes KT-10809: code no longer compiles.
Change resolution to consider extensions to implicit receiver before members of another implicit receiver.
Make synthesized member-like extensions resolve right after the members.
#KT-10510 Fixed
#KT-10219 Fixed
- 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
Look into QUALIFIER for left-most "unrolled" qualified expression
in CallExpressionResolver#getQualifiedExpressionTypeInfo.
Drop some unused functions.
Denis Zharkov