[LLVMdev] Non-clang warning cleanliness in the LLVM project

[David Blaikie]

So a while back we took a moderately aggressive stance on disabling GCC
warnings with false positives, specifically those related to uninitialized
variables. In cases where GCC suggested initializing a variable yet the
algorithm was safely initializing the variable, adding the GCC-suggested
initialization could thwart tools like MSan/ASan. So it was suggested that
we should not abide by GCC's warning and rely on Clang's more carefully
limited warning without the problematic false positives.

Recently Andy Kaylor's been working on getting the MSVC build warning clean
by a combination of disabling warnings and fixing a few cases of relatively
low frequency.

I've generally been encouraging people to aggressively disable non-clang
warnings whenever there's a false positive (anything other than a bug, or
at least anything that doesn't strictly improve readability) and one such
instance of this is in the review for r233088 which amounts to something
like:

template<typename T>
int func(T t) {
  return t.func() >> 8;
}

(it's more complicated than that, but this is the crux of it) - for some
instantiations of this template, T::func returns an 8-bit type, and MSVC
warns that the shift will produce a zero value. The code is correct (the
author intended this behavior, because some instantiations produce a
wider-than-8-bit- type and the higher bits are desired, if present).

I suggested disabling this warning, but that would mean we miss out on the
true positives as well (Clang doesn't seem to have any warning like this),
though we haven't seen these very often.

How do people feel about working around this warning so we can keep it
enabled?
How do people feel about disabling this warning?
How do people feel about disabling other non-Clang warnings which have
false positives?

(in the case of Clang warnings with false positives we should take the same
approach, except we also have the option to improve the quality of the
warning by fixing Clang, which is what we generally try to do)

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/577c4c7f/attachment.html>