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
In Swift 5 and earlier initializer references are handled in a special
way that uses a type variable to represent a type of the parameter
list. Such type variables should be allowed to bind to a pack expansion
type to support cases where initializer has a single unlabeled variadic
generic parameter - `init(_ data: repeat each T)`.
If generic parameter comes from a variadic type declaration it's
possible that it got specialized early and is no longer represented
by a pack expansion type. For example, consider expression -
`Test<Int>(42)` where `Test<each T>` and the initializer
is declared as `init(_: repeat each T)`. Although declaration
based information reports parameter at index 0 as variadic generic
the call site specializes it to `Int`.
Resolves: rdar://107151854
Pack expansion types are handled by matching logic, optimization
that attempts to propagate types into the body of the closure should
consider them unsuitable even if the pack expansion matches a single
parameter.
Remove a bit of logic from `matchCallArgumentsImpl` that prevented
unlabeled argument matching after pack expansion argument until next
labeled argument because it incorrectly assumed that it represents
variadic forwarding.
