[cfe-dev] -Wunreachable-code and templates

[David Blaikie]

On Thu, Mar 15, 2012 at 7:51 PM, Ted Kremenek <kremenek at apple.com> wrote:
>
> 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.  :)

Sure thing - makes sense & I'll leave further discussion for later.
For now I'm happy enough just to generally make things "better" & we
can cross other bridges (self hosting in the Clang/LLVM build, adding
to -Wall, making it on-by-default, etc) as we reach them.

- David