martong added inline comments.
================
Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:429-435
+ const ExplodedNode *N = BR.getErrorNode();
+ while (N && N != NotePosition) {
+ const StreamState *StreamS = N->getState()->get<StreamMap>(StreamSym);
+ if (!StreamS || !StreamS->ErrorState.FEof)
+ return "";
+ N = N->getFirstPred();
+ }
----------------
balazske wrote:
> balazske wrote:
> > NoQ wrote:
> > > This code says "If there exists a state below in the path where the
> > > stream is not at EOF, drop the note". The report will not be emitted at
> > > all if the stream is not at EOF at the end, right? Are you trying to
> > > account for the situation when the stream gets reset into a non-EOF state
> > > and therefore you don't need to emit the note above that point?
> > >
> > > In such cases the intended solution is to add another note tag to mark
> > > the stream uninteresting once it gets reset, because all the history
> > > before that point is irrelevant to our report entirely (whatever the
> > > previous position was, its get completely overwritten by the reset).
> > >
> > > The API for marking objects uninteresting is not yet there but it's
> > > suggested in D104300. I believe you should rebase your patch on top of it
> > > and take advantage of it as it lands.
> > It was unknown to me if the visit of `NoteTag`'s happens from the bug path
> > end to begin or in different way. If it is from end to begin it may be
> > enough to remove the interestingness in the current `NoteTag` function when
> > a message is produced, it should find exactly the last place where that EOF
> > flag is set to true. And `NotePosition` is not needed.
> I tried it out, seems to work. But to continue D104300 should be finished or
> the "reset of interestingness" must be split to a separate change (or into
> this patch), is this possible?
> I tried it out, seems to work. But to continue D104300 should be finished or
> the "reset of interestingness" must be split to a separate change (or into
> this patch), is this possible?
Yes, I think it would be the logical way forward if we want a smooth
development with this change. So let's create a parent patch that implements
solely `markNotInteresting` from D104300. And that new patch should be the
parent of this patch, also D104300 could be rebased once the new patch of
`markNotInteresting` is landed.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D104925/new/
https://reviews.llvm.org/D104925
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
