[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
chandlerc at google.com
Thu Feb 3 00:46:05 PST 2011
(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
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...
More information about the cfe-commits