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
[SR-6316] False-Positive Switch Exhaustiveness Check results in Bad Access / Bad Instruction at Runtime #48866
Comments
cc CodaFi (JIRA User) |
@swift-ci create |
Oh, I see. The reason it takes 9 bools is the generated space has size 2^9 = 512, which means the space engine falls back to a heuristic that checks to see if we've diagnosed any of the patterns as overlapping. This space built from this carefully-crafted set of cases is eluding that check and registering with size slightly greater than 512 which fools the heuristic. |
Gotcha! #12818 |
Comment by Fabian Ehrentraud (JIRA) @CodaFi this is very interesting. Where is the threshold for the space engine? |
I have it artificially limited to 2^7=128 to prevent foisting enormous fixits upon the user. It Would Be Nicer ™ from a QoI perspective to look into doing what GHC does here: Pop a diagnostic and suggest the first three or so missing cases with some ellipses to indicate the analysis is incomplete. |
Comment by Fabian Ehrentraud (JIRA) @CodaFi will associated values of enum cases count into that number, or are |
This got reverted, so I'm reopening the bug. |
Here's another example from the new Radar:
|
Environment
Xcode 9.1.0
Additional Detail from JIRA
md5: 812f6c41ea662cfe91de3e96db924ef7
is duplicated by:
relates to:
Issue Description:
This is a serious issue that results in runtime crashes.
Seems like the compiler does not calculate exhaustiveness for nested tuples correctly.
The text was updated successfully, but these errors were encountered: