Re: Implement -Wimplicit-fallthrough (version 9)

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Sep 27, 2016 at 12:56:29PM +0200, Marek Polacek wrote:
> 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.
> 
> I'm thinking perhaps we should also accept /* ... fall through ... */
> and /* else fall through */, but accepting any sentence containing "fall" and
> "through/thru/etc" on the same line would mean that we also accept
> /* Don't fall through here.  */ and that is clearly not desirable.

I think it is important to think in terms of what regexps we still want to
match, even when the matching is actually implemented in C, not using
regexps.  And yes, you list one reason why arbitrary text with fall and
through somewhere in it is not a good idea.  Another:
/* XXX Really fallthru?  */
(what we have in pch.c).
So, if you want to allow ... fall through ... and else fall through, and
perhaps // fall through - some explanation
then it might be e.g.
//-fallthrough$
//@fallthrough@$
/\*-fallthrough\*/
/\*@fallthrough@\*/
//[ \t.]*(ELSE )?FALL(S | |-)?THR(OUGH|U)[ \t.]*(-.*)?$
//[ \t.]*(Else )?Fall(s | |-)?[Tt]hr(ough|u)[ \t.]*(-.*)?$
//[ \t.]*(else )?fall(s | |-)?thr(ough|u)[ \t.]*(-.*)?$
/\*[ \t.]*(ELSE )?FALL(S | |-)?THR(OUGH|U)[ \t.]*(-.*)?\*/
/\*[ \t.]*(Else )?Fall(s | |-)?[Tt]hr(ough|u)[ \t.]*(-.*)?\*/
/\*[ \t.]*(else )?fall(s | |-)?thr(ough|u)[ \t.]*(-.*)?\*/
where . would match even newlines in the last 3,
but $ would always match just end of line?

	Jakub