`TypeSimplifier` may not eliminate type variables from e.g the
pattern types of pattern expansion types since they can remain
unresolved due to e.g having a placeholder count type. Make sure we
eliminate any remaining type variables along with the placeholders.
There's probably a more principled fix here, but this is a quick and
low risk fix we can hopefully take for 6.2.
rdar://154954995
If closure appears inside of a pack expansion, the elements
that reference pack elements have to bring expansion's shape
type in scope to make sure that the shapes match.
Type variable reference collector needs to be augmented to collect
type variables associated with pack expansions that a closure references
elements of, otherwise it would get disconnected from the context.
We used to disallow pack expansions in generic argument lists of
protocols, but allow them for all other nominal types. However,
we only actually checked that the pack expansions match up if
the type itself was variadic.
Fix this by repurposing Context::ProtocolGenericArgument into
Context::ScalarGenericArgument, and using that when the type does
not have a parameter pack.
Context::GenericArgument is now Context::VariadicGenericArgument,
and we only use it if the type has a parameter pack, in which case
we use the PackMatcher, so any pack expansions in the wrong place
are caught there.
Fixes rdar://116716014 and https://github.com/apple/swift/issues/69088.
Such tuples should be treated specially because once pack expansion
is sufficiently resolved they'd get exploded and the resulting type
is what member lookup should use as a base.
Resolves: rdar://110721928
If one of the choices is variadic generic, let's use `matchCallArguments`
to find argument/parameter mappings and form pack expansions for arguments
when necessary.
Resolves: rdar://112029630
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
stripping PackType out of diagnostic arguments.
There are places in the type printing code that assume the substitution for a
type parameter pack is always a pack, and violating that invariant will crash
the compiler. We also never want to print 'Pack{...}' in diagnostics anyway,
so the print option is a better approach and fixes a few existing tests that still
contained 'Pack{...}' in error messages.
type.subst in mapTypeIntoContext.
The outer context substitutions are already applied when invoking
QueryInterfaceTypeSubstitutions. Applying the context substitutions
before subst also causes problems because QueryInterfaceTypeSubstitutions
will return a null type if given an archetype, which manifested with
opened pack element environments.
This covers situations like `Pack{repeat each T1, repeat each T2}`
vs. `Pack{repeat $T1, repeat $T2}` where type variables are allowed
to bind to packs.
Resolves: rdar://109539394
Don't attempt to wrap `Any` into a single-element tuple to match
against a tuple with pack expansions, this conversion would be
handled by existential promotion if it's allowed, otherwise it
would produce an error.
Resolves: rdar://109160060
