-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Sema: Respect TVO_CanBindToPack #61777
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
7289baa
to
0b8927c
Compare
// can't merge these two type variables. | ||
if (rep1->getImpl().canBindToPack() | ||
!= rep2->getImpl().canBindToPack()) | ||
return getTypeMatchFailure(locator); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of failing should this just from an unsolved constraint and wait until one of type variables is resolved so it could be fixed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TVO_CanBindToPack should never change. It's set when the type variable is created in CSGen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's reasonable but we cannot diagnose here and at the same time cannot fail right away either I think, we need to waiting into more is know about one of the types or it's marked as a placeholder...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, we can't unconditionally fail. When Pavel says "so it could be fixed", I think he means that this constraint needs to ultimately return SolutionKind::Solved
in diagnostic mode with some kind of fix recorded. The solver should never fail solving a constraint in diagnostic mode.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should never fail solving a constraint in diagnostic mode
Shouldn't fail unless it leads to a worse solution i.e. if the impact of the fix is greater than previous solutions that have been discovered.
@@ -4307,6 +4307,14 @@ ConstraintSystem::matchTypesBindTypeVar( | |||
} | |||
} | |||
|
|||
if (type->is<PackType>() || type->is<PackArchetypeType>()) { | |||
if (!typeVar->getImpl().canBindToPack()) | |||
return getTypeMatchFailure(locator); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a bi-directional fix here similar to fixReferenceMismatch
otherwise constraint solver is just going to fail with "failed to produce a diagnostic" because it wouldn't be able to form a valid solution due to this binding always failing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll let @hborla handle this one :) I was just rebasing this PR so that she could finish it off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'm going to pick this up and address the feedback about diagnostics!
Subsumed by #64498 |
No description provided.