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

• rename the rule to ImplicitSwitchFallThrough see [java] Rename rule MissingBreakInSwitch to ImplicitSwitchFallThrough #3361
• flag all instances of fall through.
• report violation on the individual switch cases that fall-through, and not the whole switch statement
• allow suppression via @SuppressWarnings("fallthrough") (refs [java] Full @SuppressWarnings support #1900), and comments like // fallthrough, that make the fallthrough behavior evident to the reader.
• consider switch expressions see [java] ImplicitSwitchFallThrough should consider switch expressions #3362

Describe alternatives you've considered
None

Additional context

This will fix

• [java] Recognize @SuppressWarnings("fallthrough") for MissingBreakInSwitch #1899
• [java] MissingBreakInSwitch - last default case does not contain a break #659, [java] MissingBreakInSwitch detects the lack of break in the last case #2579 (maybe, those are duplicates, but the newer one is clearer)

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