Implement -Wimplicit-fallthrough (version 9)

[Jakub Jelinek]

On Tue, Sep 27, 2016 at 12:47:50PM +0200, Jakub Jelinek wrote:
> On Tue, Sep 27, 2016 at 12:39:41PM +0200, Markus Trippelsdorf wrote:
> > On 2016.09.27 at 10:46 +0200, Eric Botcazou wrote:
> > > > The intent has been that we catch the most common forms, but still require
> > > > it not to be complete free form.  Because, as experience shows, people are
> > > > extremely creative in these comments, and it is not very good idea to
> > > > support everything.  For ... fall through ... , what is the purpose of
> > > > those ...s?
> > > 
> > > No idea, but it has been there for a while and seems perfectly reasonable.
> > > IMO any sentence containing "fall" and "through/thru/etc" on the same line 
> > > should be accepted, otherwise it's just misplaced pickiness.
> > 
> > +1. Folks will just disable the warning if gcc is not very permissive
> > when paring existing comments. You cannot expect anyone to change
> > perfectly fine fall-through comments just to accommodate an arbitrary
> > gcc style.
> 
> The accepted style is already very permissive, we don't allow just one
> spelling as various lint tools.  I'm afraid looking for various cases of
> fall and through/thru possibly separated by anything and surrounded by
> anything is IMHO already too much, the compiler shouldn't try to try to
> grammar analyze the comments on what they actually talk about and whether it
> might be related to the switch fall through or something completely
> different.  Users should start using [[fallthrough]]; anyway.

Oh, forgot, I think allowing
  /* Fallthrough */
  /* arbitrary comment */
  case ...
might be something we could be also supporting, especially because
sometimes users might want to comment on what the following case handle and
fallthrough would be just something in between.  But IMHO forcing users to
use some clear markup style if they don't want to/can't switch to
[[fallthrough]];
__attribute__((fallthrough));
or some macro that does that is a good idea.  That will certainly increase
the chance other compilers could do the same thing, parsing arbitrary stuff
is hard to agree on.

	Jakub