On Mar 28, 2013, at 5:50 PM, Jordan Rose <[email protected]> wrote:
> I'm sad to have another one-shot visitor, rather than just doing the work up
> front in trackNullOrUndef.
Is there a policy on when we should walk up the path up front vs when we should
do it in the visitors? Currently, we seem to be mixing both, sacrificing the
cleanness of the code.. I thought that we had decided to go with visitors from
now on. We could redesign that code/try to improve performance more if we think
this approach is generally too slow.
> Now that suppression can take a significant portion of analysis time, we
> should probably not add new visitors as freely as we once would have.
>
>> + // The message send could be null if the receiver is null.
>> + if (const Expr *Receiver = NilReceiverBRVisitor::getReceiver(S)) {
>> + report.addVisitor(new NilReceiverBRVisitor(Receiver,
>> + EnableNullFPSuppression));
>> + }
>> +
>
> if (...) {
> trackNullOrUndefValue(N, Receiver, report);
> }
>
The receiver might not be nil. Logically, we should only register to track it
if it is indeed nil. We cannot know if it is nil or not until we walk up the
path to find the node where it has a value. Using the existing visitor to do
this seems to be the cleanest approach. That was the motivation for doing it
this way.
> This seems much more efficient—no restarting of path generation due to the
> new visitor.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
