[llvm-commits] [llvm] r158638 - in /llvm/trunk: include/llvm/ADT/DenseMap.h unittests/ADT/DenseMapTest.cpp

[Duncan Sands]

Hi Nick,

>> We should rely on Clang's -Wuninitialized and on Valgrind to catch our bugs.
>
> I agree with this in this case, but it hasn't escaped my attention that LLVM has
> always had a "no warnings allowed" policy which we've applied evenly across all
> situations (see http://llvm.org/docs/DeveloperPolicy.html#quality ). Since I
> think this is a legitimate problem, I want to discuss what the policy ought to be.
>
> We should err heavily towards the side of respecting the compilers warning,
> except when we know that the compiler warning is Plain Broken (as it is here).
> We should have a list of warning+compiler pairs that are known broken (perhaps
> next to the brokengcc list?).
>
> The reason that the old policy doesn't work any more is that as we've grown
> we've picked up more users using more distinct versions of more compilers than
> ever before, and our probability of hitting a badly implemented warning (even
> one that's just-a-bug from the compiler vendor) is going up.
>
> If folks agree with this, we should probably prepare a patch to the
> DeveloperPolicy to update its text slightly, and start our list somewhere.

personally I don't want any warnings when *I* build LLVM.  That's because I want
any new warnings to stand out, so I notice and analyse them, rather than having
them be lost in a sea of existing warnings.  I think it is impossible to have
LLVM build with no warnings for all compilers.  But I reckon it is reasonable
to deal with warnings that LLVM developers are actually seeing.  The fact that
end users may see some warnings doesn't much bother me.

Ciao, Duncan.