-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Enhance switch on non-exhaustive enums #24381
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
c97a209
to
057d8f6
Compare
I will try to rebase on top of writergate and look into the CI failures until tomorrow. |
057d8f6
to
34abbdf
Compare
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.
Amazing work wrangling Sema's switch logic; it's borderline impenetrable. Just one small nitpick about your behavior test; once you fix that and rebase, I'll be happy to hit merge.
By the way, as mentioned on another PR of yours, these lines in test cases are redundant:
// backend=stage2
// target=native
It's be good if you could drop them from your newly-added cases. Thanks!
Mainly affects ZIR representation of switch_block[_ref] and special prong (detection) logic for switch. Adds a new SpecialProng tag 'absorbing_under' that allows specifying additional explicit tags in a '_' prong which are respected when checking that every value is handled during semantic analysis but are not transformed into AIR and instead 'absorbed' by the '_' branch.
… statements If both are used, 'else' handles named members and '_' handles unnamed members. In this case the 'else' prong will be unrolled to an explicit case containing all remaining named values.
34abbdf
to
0ecbd5a
Compare
Thank you! |
Great work, thank you! |
else => {}, | ||
_ => return error.TestFailed, |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
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.
It's completely order independent, just like you could already put else
or _
at any position. The only limitation is that the else
prong cannot have any additional explicit cases specified, this isn't a new limitation though.
Closes #19438
Closes #12250
More details in commit messages
The commits are mostly separate but the second one is still based on the first one. If only one gets accepted I am happy to rebase accordingly.