-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Diagnostics] Handle CoerceExpr conversion failure in contextual mismatch #29011
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] Handle CoerceExpr conversion failure in contextual mismatch #29011
Conversation
@LucianoPAlmeida Thank you, I'll take a look on Monday! Meanwhile, can check you check how much fails if you remove |
Sure @xedin, will check as soon as possible 👍 |
@xedin removing
I do remove some obsolete code from it, but can try to figure out the missing cases in a follow-up PR so it can be removed for good \o/ |
@LucianoPAlmeida That would be great! |
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.
Looks great! I have left a minor naming suggesting inline.
@swift-ci please smoke test |
@xedin Thanks, I'm starting to work on handle the other failures, maybe we'll have something soon :) |
Sounds good, thank you! |
While working in #27895, more specifically in 82529a6 I note that the cannot convert diagnostic for expr
Double(1) as Double as String
is being emitted via fix but still going re-typechecking passing throughCSDiag
. Note that actually when tried to put aif (Options.contains(ConstraintSystemFlags::SubExpressionDiagnostics))
inapplySolutionFixes
.So this PR is to handle coercion conversion error early on
repairFailures
and avoid this.This also handles the TODO diagnostic in
test/type/subclass_composition.swift
.cc @xedin @hborla :))