haowei added inline comments.
================
Comment at: lib/StaticAnalyzer/Checkers/MagentaHandleChecker.cpp:483-498
+void MagentaHandleChecker::checkPreStmt(const ReturnStmt *RS,
+ CheckerContext &Ctx) const {
+ ProgramStateRef State = Ctx.getState();
+ const StackFrameContext *SFCtx = Ctx.getStackFrame();
+ if (!SFCtx || !SFCtx->inTopFrame())
+ return;
+ const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(SFCtx->getDecl());
----------------
NoQ wrote:
> xazax.hun wrote:
> > NoQ wrote:
> > > I think the analyzer core should do this. This code already has a global
> > > effect on the analysis - it's enough for one checker to generate the
> > > sink. Additionally, there's also the CFG-based variant of
> > > suppress-on-sink, which would need to be extended to support this as well
> > > - this other variant kicks in when the analysis was interrupted before
> > > reaching the sink (see D35673 and D35674).
> > Do we want to do this unconditionally? Are all of the resources cleaned up
> > on all of the supported OSes, or maybe for some leak issues it still makes
> > sense to warn in these cases? Or we simply favor false negatives over false
> > positives in this case (might make sense)?
> We could add a flag to `setSuppressOnSink()` as an orthogonal change if it
> turns out that we need it; i'm not aware of any stuff that badly needs to be
> cleaned up before normal program termination in the existing checkers.
I also think this should be done in a separate checker like
NoReturnFunctionChecker or within the analyzer as some other resource leak
checkers might need this. I am also thinking D36475 should be in a separate
checker as well. That annotation support really helps us a lot in analyzing
unit test code and it might be useful for others if someone run into similar
situation like us. But I cannot decide if we should use the annotate attribute
or define a new attribute just for the analyzer.
https://reviews.llvm.org/D36251
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
