IRGen: Terrible workaround for problem in searchNominalTypeMetadata() #85357
+62
−1
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.
This fixes a regression introduced by e3c8f42, but the root cause was actually a subtle invariant violation in IRGen.
FulfillmentMap's use of canonical types as keys assumes that canonical type equality is sufficient for checking if two types "are the same". However, this is not true when those types contain type parameters, because two distinct type parameters might belong to the same equivalence class.
Thus, when we take the type's context substitution map, and apply it to each type parameter in our given list of requirements, the substitution operation could output a different but equivalent type parameter.
As a workaround for this problem, try to preserve the old behavior of subst() in this specific case.
Fixes rdar://160649141.