-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Stricter enforcement of the "large space" heuristic #12818
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1031,7 +1031,8 @@ void PatternMatchEmission::emitDispatch(ClauseMatrix &clauses, ArgArray args, | |
} else { | ||
Loc = clauses[firstRow].getCasePattern()->getStartLoc(); | ||
} | ||
SGF.SGM.diagnose(Loc, diag::unreachable_case, isDefault); | ||
if (!isDefault) | ||
SGF.SGM.diagnose(Loc, diag::unreachable_case); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @jckarter Is this reasonable? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't recall the history here—why are we diagnosing this in SILGen? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just checking, since I've been out of it: we do diagnose unreachable defaults in Sema when we can, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As of now: no (and I don’t believe we should because of things like SR-3278). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah, right. I guess that's on me to put in once we switch to resilient builds with the exhaustive/non-exhaustive distinction on. |
||
} | ||
} | ||
} | ||
|
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.
@jrose-apple Here's the new diagnostic
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 the diagnostic should also include a mention of the consequence of the "too large" condition so the user knows what action to take—they just have to provide a default, right?
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.
This sounds good, along with what Joe said. We want the user to know immediately what to do next, even if there's some grumbling involved.
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.
If it doesn't require too much SourceLoc gymnastics, can we have a fixit insert
default: <#fatalError()#>
or something like that?