IRGen: Fix miscompile when a generic parameter is fixed to a tuple containing a pack #81564
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If you had something like:
We would fulfill 'each U' from the metadata for 'G<(repeat each U)>', by taking apart the tuple metadata for
(repeat each U)
and forming a pack.However this code path was only intended to kick in for a tuple conformance witness thunk. In the general case, this optimization is not correct, because if 'each U' is substituted with a one-element pack, the generic argument of
G<(repeat each U)>
is just that one element's metadata, and not a tuple. In fact, we cannot distinguish the one-element tuple case, because the wrapped element may itself be a tuple.The fix is to just split off FulfillmentMap::searchTupleTypeMetadata() from searchTypeMetadata(), and only call the former when we're in the specific situation that requires it.