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

[Richard Smith]

On Fri, Nov 9, 2012 at 8:41 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Fri, Nov 9, 2012 at 8:15 PM, Ted Kremenek <kremenek at apple.com> wrote:
>> 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.
>
> Yes, this is where it gets tricky. In C++11 we had a nice syntactic
> slot to put something non-ugly. Nonetheless, we expected people to
> wrap it in some kind of compatibility macro, and I think we would have
> the same expectation of whatever solution we pick for the
> outside-C++11 case. Given that, perhaps it's not terrible to pick
> something ugly?
>
> If you think the aesthetics of the raw annotation really matters, I
> think the least ugly option open to us would be to predefine a
> "__fallthrough" macro, which could expand to __builtin_fallthrough(),
> or to some keyword (perhaps even a __fallthrough keyword). Having this
> be detectable by the preprocessor seems useful, so that people can
> easily write portable code:
>
> #ifdef __fallthrough
> #define fallthrough __fallthrough
> #else
> #define fallthrough do {} while (0)
> #endif
>
> (With the C++11 attributes approach, we were using
> __has_warning("-Wimplicit-fallthrough") for this.) That said, I view
> the bar for a new keyword or predefined macro as being higher than
> that for a new builtin, in part due to the increased risk of breaking
> existing code.

OK, I'm no longer quite so worried about breaking code with the
predefined macro... I've done some searching, and the *only* uses I've
found of __fallthrough as an identifier were cases where it was being
used for exactly this purpose already. It seems that Microsoft's SAL
defines it as a macro for exactly this purpose.