[cfe-dev] -Wunreachable-code and templates

[Ted Kremenek]

On Mar 15, 2012, at 7:39 PM, David Blaikie <dblaikie at gmail.com> wrote:

>> The performance numbers seem very reasonable for this to be a useful warning, although I still don't think it would be on by default.
> 
> -Wunreachable-code certainly isn't up to on-by-default yet, but do you
> mean that the template-unreachability would be treated separately/not
> on-by-default even once we fix the non-template false positives (like
> sizeof) (or a 3rd option - you think unreachable-code overall
> (template & non-template) would never be on-by-default for some
> reason)?

No, I'm talking about the whole thing.

> 
>>  I'm also wondering how much more stuff we can put under -Wall that runs into stylistic preferences, but we can have that debate later.
> 
> Unreachable code as a stylistic preference such as the ways you can
> have deliberately unreachable code (like the current "if (0)" in
> LLVM/Clang code), or something else?

Yes, and any other idiomatic code we haven't thought about yet where users are going to prefer we didn't warn them.  Users can be rather picky about warnings.  :)

The problem I see in this case is that some dead code is potentially idiomatic, so we need to take care about when and if we can make this a default enabled warning, or even add it to -Wall.  In general, I'm concerned about pulling more and more warnings into -Wall without a clear sense of expectations or guidelines.  Our own experience at Apple and from our external users has shown that as Clang has gained adoption it becomes increasingly problematic to roll out new default warnings or simply add them under -Wall because of (a) code that builds with -Werror will break or (b) we simply are not matching user expectations of what kind of warnings they expect to see from the compiler.  Both cases ends up pissing people off when we were trying to deliver added value.  I see this problem only compounding as we add more and more (genuinely awesome) warnings to Clang.  I think we may need to consider a more cohesive long term strategy on how and when new warnings are rolled out to !
 users.

I don't want to derail this thread with a discussion about this topic; instead I'd rather have a focused discussed with an actual proposal, and I don't have one right now.  :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120315/d065cc30/attachment.html>