Skip to content
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

Fix warning C26818 about switch statements needing default cases #4715

Merged
merged 9 commits into from
Jun 18, 2024

Conversation

StephanTLavavej
Copy link
Member

@StephanTLavavej StephanTLavavej commented Jun 8, 2024

Fixes DevCom-10670613 VSO-2081258 / AB#2081258.

In general, we haven't attempted to be clean with respect to Core Guidelines warnings, as many of them are noisy and/or inappropriate for Standard Library code. However, warning C26818 "Switch statement does not cover all cases. Consider adding a 'default' label (es.79)." aligns with our conventions. We always like to have a default as a reminder to think about what happens when none of the cases are selected (this is one of the relatively few scenarios where we like to write code that isn't necessary). The only exception to this convention is when we're switching on an enum and we've handled all of the enumerators (it can still be okay to have a "can't happen" default, but sometimes we don't bother), which fortunately this warning doesn't complain about.

I added test coverage for all of these fixes, i.e. removing any fix will cause GH_002094_cpp_core_guidelines to fail.

All of the empty default: break; cases being added are used, i.e. making them abort() will cause other tests to fail.

In <format>, we have a couple of "can't happen" cases, where I've added _STL_UNREACHABLE with comments explaining why.

In <xlocmon>, we have default cases that can only be activated by users giving us a bogus money_base::pattern, so I've added _STL_ASSERT(false, "message") citing the same Standardese each time.

While auditing all of our switch statements (which is how I found half of these), I found a few cases in old code where we weren't obeying our syntax convention: a switch's last case or default must always break. Falling off of the end is an unacceptable maintenance hazard.

Finally, I removed an unnecessary, inconsistent comment in <xlocmon>.

Also remove an unnecessary, inconsistent comment.
These are all covered by the test.

Cite the Standard to explain how we've handled all valid values.
Add a comment to explain why we've handled all cases.
These are all covered by the test.

They're all used, i.e. making them `abort()` causes tests to fail.
These are both covered by the new test.

The empty `default: break;` is used, i.e. making it `abort()` causes tests to fail.

Add a comment to explain why `_Parse_range_specs()` guarantees that the other can't happen.
This is covered by the new test.

The empty `default: break;` is used, i.e. making it `abort()` causes tests to fail.
This is covered by the new test.

The empty `default: break;` is used, i.e. making it `abort()` causes tests to fail.
@StephanTLavavej StephanTLavavej added the bug Something isn't working label Jun 8, 2024
@StephanTLavavej StephanTLavavej requested a review from a team as a code owner June 8, 2024 13:52
Copy link
Contributor

@AlexGuteniev AlexGuteniev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should use std::unreachable for "can't happen" default handlers to aid optimization

stl/inc/format Outdated Show resolved Hide resolved
stl/inc/format Outdated Show resolved Hide resolved
@StephanTLavavej
Copy link
Member Author

Sure, thanks @AlexGuteniev! 😻 Pushed a commit.

@StephanTLavavej StephanTLavavej self-assigned this Jun 14, 2024
@StephanTLavavej
Copy link
Member Author

I'm speculatively mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

@StephanTLavavej StephanTLavavej merged commit fd797a9 into microsoft:main Jun 18, 2024
39 checks passed
@StephanTLavavej StephanTLavavej deleted the switch-default branch June 18, 2024 05:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
3 participants