Functions can in fact conform to some protocols, notably,
marker protocols. Dynamically they have no influence on whether the cast
will succeed or not, as there is no way to tell if a type conforms to
such a protocol at runtime. But we should check them statically because
they otherwise can be cast to Any eventually.
Remove keypath subtype asserts; always use cached root type
Add tests for keypaths converted to funcs with inout param
Add unit test for overload selection
This removes the distinction between argument completions and postfix expr paren completions, which was meaningless since solver-based completion.
It then determines whether to suggest the entire function call pattern (with all argument labels) or only a single argument based on whether there are any existing arguments in the call.
For this to work properly, we need to improve parser recovery a little bit so that it parsers arguments after the code completion token properly.
This should make call pattern heuristics obsolete.
rdar://84809503
In asserts builds this hits an assert that the
feature isn't enabled, and in no-asserts builds
this incorrectly allows `do` expressions to be
used with the feature disabled. Note this only
affects their use when nested in an `if`/`switch`
that is used in a binding, we correctly handled
the other cases.
rdar://121193678
If root type of a key path has been determined to be a hole there
is no reason to delay the inference decision which should be a
failure because none of the components would be inferrable from
a placeholder root.
Start classifying all potential throw sites within a constraint
system and associate them with the nearest enclosing catch node. Then,
determine the thrown error type for a given catch node by taking the
union of the thrown errors at each potential throw site. Use this to
compute the error type thrown from the body of a `do..catch` block
within a closure.
This behavior is limited to the upcoming feature `FullTypedThrows`.
Follow-up to https://github.com/apple/swift/pull/70148
Just like with arrays it's advantageous to favor dictionary
literals over disjunctions to bind the elements together and
enable inference across elements and, as a consequence,
type pruning.
Resolves: rdar://119040159
Produce a tailored diagnostic that omits a fully unresolved key path
type (`KeyPath<_, _>`) when key path without an explicit root type is
passed as an argument to non-keypath parameter type (i.e. `Int`).
Since key path root is now transitively inferred. Key path type
inference can be delayed until key path is resolved enough to
infer its capability.
This solves multiple problems:
- Inference fully controls what key path type is bound to;
- KeyPath constraint simplification doesn't have to double-check
the capability and attempt to re-bind key path type;
- Custom logic to resolve key path type is no longer necessary;
- Diagnostics are improved because capability and root/value type
mismatch are diagnosed when key path is matched against the
contextual type.
Covariant conversions between explicit and contextual/inferred root
types of a key path are simulated through a subtype constraint which
has to be attached to a `KeyPathRoot` element.
If key path is connected to a disjunction directly or indirectly
(i.e. via ApplicableFunction constraint) do not attempt to bind
it until disjunction is taken, otherwise there is a risk to miss
a valid keypath-to-function conversion.
If there is something wrong with the context, let's assign a default
KeyPath type to the key path literal to avoid propagating placeholder
into the key path inference.
For methods there are two possibilities - force unwrap and
conditional, that's why we need a disjunction with two choices.
This is not the case for key path root type it could only
be force unwrapped.
A key path without an explicit root cannot be unwrapped since the
optionality is inferred from context and we cannot suggest removing
that, adding explicit type is not going to change anything and
`!` and `?` after the leading dot is not supported.
`tryMatchRootAndValueFromType` anchored both root and value match
constraints directly on the key path expression. That is incorrect
because we have special locators for that.
If key path literal is passed as an argument to a function/subscript
application its type cannot be resolved until the overload for the
call is selected, otherwise it could prevent a valid keypath-to-function
conversion in cases were argument ends up being a function type.
If type of the key path expression is convertible to an existential
value with a superclass constraint represented as a known key path
type, we can use it to inform key path inference.
Resolves: rdar://93103421
