Is your feature request related to a problem? Please describe.
Problem 1: false-negatives
MissingBreakInSwitch currently only checks that there are as many breaks as there are cases. This fails on eg
switch (a) {
case 1:
doSomethingWithoutBreak(a); // falls through
case 3:
for (...) { if (...) break; } //breaks the loop, but falls through
case 5:
if (...) break;
else if (...) break;
else { /* no break = fallthrough */ }
case 6:
break;
}
The above produces no violation as it has 4 cases and 4 breaks. However, all of those cases may fall through to next one (except the last obviously). This is because the strategy of the rule is just to count break statements.
Problem 2: naming
I think the rule's purpose is to avoid implicit fall through to the next case, as this may be unexpected. However the rule's name just describes its implementation strategy, and not particularly well, as fallthrough may also be avoided by continue, return and throw statements (cases that the rule tries to handle as well).
--> see #3361
Describe the solution you'd like
I think we should
@SuppressWarnings("fallthrough") (refs [java] Full @SuppressWarnings support #1900), and comments like // fallthrough, that make the fallthrough behavior evident to the reader.Describe alternatives you've considered
None
Additional context
This will fix
The UnusedAssignmentRule already implements an exploration pass that follows the control flow of the program. It's very easy to extend to detect whether a switch case has fallen through. In fact, it's more about extending it to give access to the information, as the information is already computed by the rule. I've done this in my branches, see MissingBreakInSwitchRule
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4