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

[Yaron Keren]

It's fairly quick to workaround a warning compared with much more time
identifying and debugging a real bug, so in total it is more efficient to
keep even high false positive rate warnings enabled.


2015-03-27 20:31 GMT+03:00 David Blaikie <dblaikie at gmail.com>:

> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150327/2e75348e/attachment.html>