This is a diagnostic that is only really emitted as a fallback when
the constraint system isn't able to better diagnose the expression.
It's not particulary helpful for the user, and can be often be
misleading since the underlying issue might not actually be an
ambiguity, and the user may well already have a type annotation. Let's
instead just emit the fallback diagnostic that we emit in all other
cases, asking the user to file a bug.
Follow-up for https://github.com/swiftlang/swift/pull/82326.
The optional injection is only viable is the wrapped type is
not yet resolved, otherwise it's safe to wrap the optional.
If we have a tuple with unresolved pack expansion on one side
and an optional type on the other, prevent `matchTypes` from
wrapping optional into a one-element tuple because the matching
should be handled as part of the optional injection.
Resolves: rdar://152940244
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.
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.
