[cfe-commits] r146174 - in /cfe/trunk: lib/Analysis/ThreadSafety.cpp lib/Sema/AnalysisBasedWarnings.cpp test/SemaCXX/warn-thread-safety-analysis.cpp

[Delesley Hutchins]

I actually started trying to do that, but it ended up being
non-trivial.  In the general case, the lock and unlock can be quite
far apart, and in different branches of the CFG, so there was a fair
amount of extra logic involved to reliably track what I've already
warned about.  My priority right now is to get the basic logic
implemented and working, and I don't want to introduce false negatives
by mistake.   I'm happy to add a FIXME, though.  :-)

  -DeLesley

On Thu, Dec 8, 2011 at 1:32 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Thu, Dec 8, 2011 at 12:45 PM, Delesley Hutchins <delesley at google.com>
> wrote:
>>
>> I don't like the second warning, but it's not necessarily all that
>> easy to get rid of it.  As with many warnings, once the compiler is
>> confused, you may get several warnings due to one mistake.  It's hard
>> to avoid that in all cases.
>
>
> But that's not really the case here. The compiler isn't confused.
>
> It seems like when you are warning about an invalid locking pattern, you
> should mark the aspects of that pattern already warned about as invalid to
> suppress subsequent warnings on them.
>
> For example, when you see a lock acquired a second time, warn about it, but
> then suppress both the acquisition and the subsequent (paired) release from
> the lockset so that you don't get further warnings.



-- 
DeLesley Hutchins | Software Engineer | delesley at google.com | 505-206-0315