[CS] Handle holes in mergeEquivalenceClasses
#83724
Draft
+133
−58
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
xedin
reviewed
Aug 14, 2025
hamishknight
force-pushed
the
hole-in-two
branch
from
5fba3d7 to
2fa4b46
Compare
hamishknight
changed the title
mergeEquivalenceClassesmergeEquivalenceClasses
hamishknight
commented
Oct 19, 2025
| Table(self.data) { | ||
| // expected-error@-1 {{expected expression of type 'Columns' in result builder 'TableColumnBuilder'}} {{23-23=<#T##Columns#>}} | ||
| // expected-error@-1 {{expected expression of type 'Column' in result builder 'TableColumnBuilder'}} {{23-23=<#T##Column#>}} | ||
| // expected-error@-2 {{generic parameter 'Column' could not be inferred}} |
There was a problem hiding this comment.
This is a little unfortunate, but it's because we're now no longer stripping TVO_CanBindToHole from the generic parameter. We can't eagerly bind the missing argument to a hole because we rely on type inference to infer the type for better diagnostics. Maybe we could rework those diagnostics to instead look at the parameter type, or maybe we could tweak the diagnostic logic for a defaulted generic parameter to account for missing argument fixes (unfortunately it currently gets defaulted before we match arguments though). In any case, I'm going to leave this as future work.
|
@swift-ci please SourceKit stress test |
We know this is where the issue is so we ought to always produce a concrete hole.
Unwrap a metatype before checking if we have an associated fix.
Make sure we preserve `TVO_CanBindToHole`. This unfortunately requires introducing the concept of a "non-representative" hole for representatives where the actual hole is given by another type variable in the equivalence class. This avoids disturbing binding order and regressing diagnostics. Once binding is less sensitive to ordering we ought to be able to always choose the hole as the representative.
hamishknight
force-pushed
the
hole-in-two
branch
from
2fa4b46 to
d8719ab
Compare
|
@swift-ci please test |
|
Oh fun this breaks swift-testing on Windows |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Make sure we preserve
TVO_CanBindToHole. This unfortunately requires introducing the concept of a "non representative" hole for representatives where the actual hole is given by another type variable in the equivalence class. This avoids disturbing binding order and regressing diagnostics. Once binding is less sensitive to ordering we ought to be able to always choose the hole as the representative.