[cfe-commits] r166728 - in /cfe/trunk: include/clang/StaticAnalyzer/Core/BugReporter/ lib/StaticAnalyzer/Core/ test/Analysis/ test/Analysis/diagnostics/ test/Analysis/inlining/

[Ted Kremenek]

On Oct 25, 2012, at 3:59 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>> /// Recursively scan through a path and prune out calls and macros pieces
>> /// that aren't needed.  Return true if afterwards the path contains
>> /// "interesting stuff" which means it should be pruned from the parent path.
>> @@ -2016,10 +2078,16 @@
>>  } while(finalReportConfigToken != originalReportConfigToken);
>> 
>>  // Finally, prune the diagnostic path of uninteresting stuff.
>> -  if (!PD.path.empty() && R->shouldPrunePath()) {
>> -    bool hasSomethingInteresting = RemoveUneededCalls(PD.getMutablePieces(), R);
>> -    assert(hasSomethingInteresting);
>> -    (void) hasSomethingInteresting;
>> +  if (!PD.path.empty()) {
>> +    // Remove messages that are basically the same.
>> +    RemoveRedundantMsgs(PD.getMutablePieces());
>> +
>> +    if (R->shouldPrunePath()) {
>> +      bool hasSomethingInteresting = RemoveUneededCalls(PD.getMutablePieces(),
>> +                                                        R);
>> +      assert(hasSomethingInteresting);
>> +      (void) hasSomethingInteresting;
>> +    }
> 
> It's probably cheaper to do this in the other order.

Hi Jordan,

That is true, but I think RemoveUneededCalls should always come last, after we have done all of other passes over the PathPieces.  The idea is that the more we remove from the path, there is a higher chance that RemoveUneededCalls will be able to remove a call.  That won't apply in this scenario because of how RemoveRedundantMsgs works, but it's something that would be easy to get wrong if we added more "passes" like this where the implications are slightly different.

Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20121026/25da855f/attachment.html>