Binding of pack expansion types is delayed until solving but use
of `Defaultable` was preventing it from being considered early
because that constraint impacts binding set ranking, switching
to `FallbackType` constraint give us better semantics where pack
expansion type variables are going to be bound as soon as they
have a contextual type.
Resolves: rdar://110819621
If generic parameter gets opened during regular solving it cannot
be bound to a hole, that can only happen in diagnostic mode, so
let's not even try. Doing so also makes sure that there are no
inference side-effects related to holes because bindings are ranked
based on their attributes.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
There's still plenty of more work to do here for
pattern diagnostics, including introducing a
bunch of new locator elements, and handling things
like argument list mismatches. This at least lets
us fall back to a generic mismatch diagnostic.
If function type of some declaration has a at least on type parameter
pack it could mean that number of parameters in "applied" type could
be different from that of "interface" type.
If there are multiple overloads, let's skip locations that produce
the same type across all of the solutions, such location is most
likely a consequence of ambiguity and not its source.
Resolves: rdar://109245375
Opened existentials should be erased to the dependent upper bound
if the dependent member can be reduced to a concrete type. This
allows the generic signature to support parameterized protocol types
and bound generic class types by producing a more specific constraint
instead of just a plain protocol or class.
If there are explicit generic arguments that fully resolves the
pack expansion, let's bind opened pack expansion to its contextual
type early (while resolving pack expansion variable), doing so
helps with performance and diagnostics.
`openType` didn't need a locator before it was simply replacing generic
parameters with corresponding type variables but now, with opening of
pack expansions types, a locator is needed for pack expansion variables.
Replace all `PackExpansionType` with a special type variable
which would be resolved once the solver determines that there
is enough contextual information.
Pack expansion type variable can only ever have one binding
which is handled by \c resolvePackExpansion.
There is no need to iterate over other bindings here because
there is no use for contextual types (unlike closures that can
propagate contextual information into the body).
If a pattern type of a pack expansion doesn't have all of the "pack capable"
type variables bound, we don't know what the structure is yet and expansion
cannot be flattened.
Models `PackExpansionType` as a type variable that can only
bind to `PackExpansionType` and `expansion of` constraint that
connects expansion variable to its pattern, shape types.
Only fully resolved substitutions are eligible to be considered
as conflicting, if holes are involved in any position that automatically
disqualifies a generic parameter.
Resolves: rdar://108534555
Resolves: https://github.com/apple/swift/issues/63450
`openGenericParameters` calls `bindArchetypesFromContext` which would bind all of the
external generic parameters in the opaque type signature.
Resolves: rdar://107280056
Substitution of a pack expansion type may now produce a pack type.
We immediately expand that pack when transforming a tuple, a function
parameter, or a pack.
I had to duplicate the component-wise transformation logic in the
simplifyType transform, which I'm not pleased about, but a little
code duplication seemed a lot better than trying to unify the code
in two very different places.
I think we're very close to being able to assert that pack expansion
shapes are either pack archetypes or pack parameters; unfortunately,
the pack matchers intentionally produce expansions of packs, and I
didn't want to add that to an already-large patch.
Enforce that we don't have any type variables
present in either the result or parameter types.
To ensure the constraint system doesn't violate
this invariant, refactor `getTypeOfMemberReference`
slightly to avoid construction of a
`GenericFunctionType` as a means of opening the
generic parameters of the context for a VarDecl.
element environments.
This allows the constraint system to ensure that for a given pack expansion locator,
the given shape class is always the same when requesting the element environment.
If the shape class differs, it means there's a same-shape requirement failure, which
will be diagnosed via the ShapeOf constraint simplification.
