if there is a non-null callee.
Otherwise, getParameterList(callee) will crash if the callee is a closure.
Closures can't have default arguments anyway, so there's no need to
attempt this new inference.
Such existential arguments will already meet the requirements of a
generic function they are passed to, but would change runtime
semantics. Therefore, don't open the existential in such cases.
When we open an existential argument in a call to a generic function,
type-erase contravariant uses of that opened existential in subsequent
parameters. This primarily impacts closure parameters, where we want
the closure to be provided with an existential parameter type rather
than permit the parameter to have opened existential type. This
prevents the opened existential type from being directly exposed in
the type system.
Note that we do not need to perform this erasure when the argument is
a reference to a generic function, because there it is suitable to
infer that the generic arguments are the opened archetypes. This
subsumes the use case for `_openExistential`.
When solving for code completion, we weren't disabling overloads because the call might be malfored in the presence of a code completion token (because the user is only now writing the function call). But this logic doesn't apply to function calls that don't even involve the code completion token, which happens if completing in result builders.
I am hoping that this significantly improves code completion performance inside result builders.
This hooks up call argument position completion to the typeCheckForCodeCompletion API to generate completions from all the solutions the constraint solver produces (even those requiring fixes), rather than relying on a single solution being applied to the AST (if any).
Co-authored-by: Nathan Hawes <nathan.john.hawes@gmail.com>
Represent this in much the same way that collections do by creating an opaque value representing the source argument, and a conversion expression representing the destination argument.
Add deep equality typing rules for
P =~= Q, T == X, U == Y, V == Z, ...
--------------------------------
P<T, U, V, ...> == Q<X, Y, Z, ...>
Also add existential matching rules to discharge the constraints on parameterized protocols against concrete types. e.g.
class C: P { typealias T = Int }
func foo<T>(_ x: P<T>) {}
foo(C())
Should cause T to unify against C.T = Int
This ensures that opened archetypes always inherit any outer generic parameters from the context in which they reside. This matters because class bounds may bind generic parameters from these outer contexts, and without the outer context you can wind up with ill-formed generic environments like
<τ_0_0, where τ_0_0 : C<T>, τ_0_0 : P>
Where T is otherwise unbound because there is no entry for it among the generic parameters of the environment's associated generic signature.
Augment the constraint solver to fallback to implicit `~=` application
when member couldn't be found for `EnumElement` patterns because
`case` statement should be able to match enum member directly, as well
as through an implicit `~=` operator application.
`repairFailures` needs a special case when l-value conversion is
associated with a result type of subscript setter because otherwise
it falls through and treats result type as if it's an argument type,
which leads to crashes.
Resolves: rdar://84580119
Adds support for parameter types like `[T?]` or `[(T, U?)]`,
and relaxes restriction on same-type generic parameters.
A same-type requirement is acceptable if it only includes
in-scope generic parameters and concrete types i.e. `T.X == Int`
if accepted if `T` is referenced only by a parameter default
expression is being applied to.
This reverts commit 6e7fff7e65283ae9b25116fa6b75ba92fd2f2a58. The
asymmetry between opening for optional parameters and optional
arguments is surprising enough that we're currently opting not to
allow them.
