-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Diagnostics] Remove FailureDiagnosis::diagnoseParameterErrors
from CSDiag
#29734
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
[Diagnostics] Remove FailureDiagnosis::diagnoseParameterErrors
from CSDiag
#29734
Conversation
@LucianoPAlmeida I'll try to take a look tonight, thank you! |
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.
Overall I think this is a way to go but since @hborla is working on changed to diagnoseAmbiguityWithFixes
she should take a look as well.
@@ -2765,6 +2765,9 @@ bool ConstraintSystem::diagnoseAmbiguityWithFixes( | |||
ParameterList, | |||
/// General ambiguity failure. | |||
General, | |||
/// Argument mismatch ambiguity where each solution has the same | |||
/// argument mismatch fixes for the same call. | |||
ArgumentMismatch |
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 believe that could be generalized to all fixes. That is exactly something @hborla is about to open a PR for, it would cover not only argument mismatches but any ambiguity which involves the same fix kind at a shared location :)
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.
Do you mean the same callee location? because in those cases all the fixes are the same, but each one for an argument. e.g. In the case of
func f<T>(_: T, _: T) {}
f(Int(1), Float(1))
There is a fix located at arg #1 in the first solution which was attempted (Int, Int)->Void
and another at #0
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.
Yeah, the two fixes here have different locators so it's not quite the same case as N common fixes across N solutions
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.
Actually, maybe the locator doesn't matter. With my changes here, I've implemented a special method on CSFix
for diagnosing for ambiguity when the fix is "common" across all solutions, but I consider a fix "common" only when the locator is the same. Instead of assuming that the locator must be the same, we can let the particular fix kind decide what it means to be "common"
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.
Humm ... so in for these case for AllowTupleTypeMismatch
and AllowArgumentMismatch
fixes will be special cases where we could ignore locator for common to be able to disambiguate.
0b7d316
to
70a284c
Compare
70a284c
to
46092af
Compare
Thank you for porting this @LucianoPAlmeida ! We are so close to removing CSDiag completely, and we really appreciate you continuing to help out! As Pavel mentioned, I'm rewriting func f<T>(_ i: T, _ j: T) {}
let _ = f(Int(3), Float(2.5)) by looking at the type variable binding for generic parameter |
@swift-ci please smoke test |
This removes some obsolete code involving argument-to-param from
repairFailures
.Removing
FailureDiagnosis::diagnoseParameterErrors
from CSDiag and fixing the remaining edge cases that were still being diagnosed by that. All of them related to ambiguity and generic types.e.g.
cc @xedin @hborla