xazax.hun added inline comments.
================
Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:651-652
+ } else if (StoreSite->getLocation().getAs<BlockEntrance>()) {
+ os << "Reach the max loop limit.";
+ os << " Assigning a conjured symbol";
+ if (R->canPrintPretty()) {
----------------
zaks.anna wrote:
> xazax.hun wrote:
> > zaks.anna wrote:
> > > MTC wrote:
> > > > NoQ wrote:
> > > > > This is user-facing text, and users shouldn't know about conjured
> > > > > symbols, and "max" shouldn't be shortened, and i'm not sure what
> > > > > else. I'd probably suggest something along the lines of "Contents of
> > > > > <...> are wiped", but this is still not good enough.
> > > > >
> > > > > Also could you add a test that displays this note? I.e. with
> > > > > `-analyzer-output=text`.
> > > > Thanks for your review.
> > > >
> > > > You are right, whether this information should be displayed to the user
> > > > is a question worth discussing.
> > > I am not convinced that we need to print this information to the user.
> > > The problem here is that it leaks internal implementation details about
> > > the analyzer. The users should not know about "loop limits" and
> > > "invalidation" and most of the users would not even know what this means.
> > > I can see how this is useful to the analyzer developers for debugging the
> > > analyzer, but not to the end user.
> > >
> > While we might not want to expose this to the user this can be really
> > useful to understand what the analyzer is doing when we debugging a false
> > positive finding. Maybe it would be worth to introduce a developer mode or
> > verbose mode for those purposes. What do you think?
> I'd be fine with that in theory, though the downside is that it would pollute
> the code a bit. One trick that's often used to better understand a report
> when debugging is to remove the path note pruning (by passing a flag). I am
> not sure if that approach can be extended for this case. Ex: maybe we could
> have special markers on the notes saying that they are for debug purposes
> only and have the pruning remove them.
>
> By the way, is this change related to the other change from this patch?
I agree that we should just commit this without the message to fix the assert.
The "debug message" could be addressed in a separate patch.
https://reviews.llvm.org/D37187
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits