[PATCH] D37187: [Analyzer] Fix Bug 25609 - Assertion UNREACHABLE: 'Unexpected ProgramPoint' with widen-loops=true

Gábor Horváth via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 25 02:36:11 PDT 2017

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. 


More information about the cfe-commits mailing list