[cfe-dev] should -Wimplicit-fallthrough require C++11?

[Ted Kremenek]

On Nov 9, 2012, at 7:04 PM, Richard Smith <richard at metafoo.co.uk> wrote:

> The original intention was that the warning could be used in any
> language mode, if you wanted a warning on *all* switch fallthrough,
> and that people who didn't want that could just not turn it on.

Right.

> I
> guess the complaints you're receiving are for situations where the
> warning can't simply be disabled (or not enabled in the first place)?

What has happened is that a fair number of users have discovered this warning using -Weverything.  When they first discover it they find it interesting.  After they discover that they cannot add an annotation (as the warning suggests) they get very frustrated.  They are then left with the choice of just turning the warning off, or using pragmas.  For those users who like the warning in principle, but find that they cannot use it in practice because of these limitations (because they are not using C++11) they view it is an incomplete feature.  Several people have thus requested to not see the warning at all.

> If we really can't find a better solution for these people than
> disabling the warning in languages where we can't annotate
> fallthrough, then we should do so consistently and disable it in C++98
> too.


Agreed, but I like your suggestion of using something like a builtin.  Right now this warnings feels like an incomplete feature.  It has a really great workflow in C++11 with the use of the attribute.  Otherwise, unless the user wants a zero-tolerance policy with this warning, the workflow is not great.  What I am afraid of is people turning this warning off (either directly or by never turning it on) when they may have found it useful.  Once they make that decision, it is unlikely they will give the warning a second try.

You may have noticed that I reverted my change, pending further discussion here.  I still think we should consider what to do for the LLVM 3.2 branch, in case this doesn't get enough attention before then.  I myself won't have any cycles over the weekend to look at this.  A builtin, however, doesn't sound so hard to implement, but I'd prefer some way to sugar coat this to avoid the ugly syntax.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121109/5838a068/attachment.html>