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
The constraint takes two pack types and makes sure that their
reduced shapes are equal. This helps with diagnostics because
constraint has access to the original pack expansion pattern
types.
Replace all `PackExpansionType` with a special type variable
which would be resolved once the solver determines that there
is enough contextual information.
Examine pack expansion pattern to determine whether expression
result could be discarded without a warning (applies to tuples
with a single unlabeled pack expansion element as well).
Resolves: rdar://108064941
Code like that is usually indicative of programmer error, and does not
round-trip through module interface files since there is no source
syntax to refer to an outer generic parameter.
For source compatibility this is a warning, but becomes an error with
-swift-version 6.
Fixes rdar://problem/108385980 and https://github.com/apple/swift/issues/62767.
`coerceCallArguments` has to be `ParameterList::getOrigParamIndex`
to determine "original" parameter version which could be used with
un-substituted parameter list.
For variadic generic declarations we need to compute a substituted
version of bindings because all of the packs are exploded in the
substituted function type.
```swift
func fn<each T>(_: repeat each T) {}
fn("", 42)
```
The type of `fn` in the call is `(String, Int) -> Void` but bindings
have only one parameter at index `0` with two argument positions: 0, 1.
If tuple doesn't have a label for its first element
and parameter does, let's assume parameter's label
to aid argument matching. For example:
```swift
func test(val: Int, _: String) {}
test(val: (42, "")) // expands into `(val: 42, "")`
```
Resolves: rdar://106775969
`openGenericParameters` calls `bindArchetypesFromContext` which would bind all of the
external generic parameters in the opaque type signature.
Resolves: rdar://107280056
