[cfe-commits] r124279 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td test/Preprocessor/pragma_diagnostic_sections.cpp test/Sema/uninit-variables.c test/SemaCXX/uninit-variables.cpp

[Chandler Carruth]

(FYI, I've been waiting to follow up here hoping for a cfe-dev targeted
thread. Should I just start one?)

I think we're actually talking a bit past each other, especially given
Chris's comment. My expectations are *not* those of GCC's flag. I really
dislike that flag's behavior for many of the reasons you've both outlined.

I like the ability to warn on potentially uninitialized variables, but that
has proven to be very hard to turn on for a large code base. I'd rather see
two flags, one targeted just as you've described at these potential errors
with reasonable tradeoffs on false positives, and a separate flag that only
flags definitively uninitialized variables. We've asked GCC to split their
warnings in this way as well. I believe the names they're going with are
"-Wmaybe-uninitialized" and "-Wuninitialized" resp., but I don't care that
much about the names used.

Anyways, I'd can write this proposal up more fully on cfe-dev, including
examples, motivations from our experience with GCC's -Wuninitialized, or
whatever would help folks weigh the various options.

To answer a couple of other specific questions...

On Mon, Jan 31, 2011 at 8:39 AM, Ted Kremenek <kremenek at apple.com> wrote:

> I am completely open to changing the flag, but as Nico pointed out the
> point of turning it on this way was to find these regressions and to measure
> people's expectations.  This is TOT, not a shipping version of Clang.
>

Just so it's clear, while this is TOT that's what we cut our releases from
and we'll have to work around this internally for now. Not a big deal, but
we try to minimize how often we have to do that to ensure we keep
upstreaming everything.

We try to release roughly bi-weekly from TOT, and are moving to weekly as
soon as we can. I'm also hoping we can turn around and offer to qualify
"beta" or other bleeding-edge-named releases on a similar time table. The
automation for this should be wrapped up in the next couple of months.


> We frequently turn on warnings and features, see how they work, and
> reevaluate.  Only a limited set of people would have provided feedback on
> the warning if I had not done this.
>

You're also welcome to send a note to cfe-dev asking for feedback on
experimental flags, and I'll try to promptly get some detailed feedback.
Maybe I've not made it clear in the past, but we have a great setup for
evaluating flag changes across a large body of both open source and closed
source code very very quickly. I would love to help anyone in the community
take advantage of it however we can. Feel free to directly ping if we can
help in this way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110203/0215bcd1/attachment.html>