[cfe-dev] Checking if a ParmVarDecl is null in a Checker

Timothy J. Wood via cfe-dev cfe-dev at lists.llvm.org
Fri Apr 27 17:21:07 PDT 2018



> On Apr 27, 2018, at 4:03 PM, Artem Dergachev <noqnoqneo at gmail.com> wrote:
> 
> Yep, indeed, this interface could be improved dramatically with a bit of work.
> 
> I'm usually getting away pretty well by searching the graph in clever manners. If your dot viewer doesn't support text search across the graph (most don't), you might want to convert it to .svg (eg. dot -Tsvg graph.dot -o graph.svg) and open the svg in a web browser and then use the find-on-page feature.
> 


Thanks for the hints!

I started printing the state pointers in my log output and that’s helping match up my log messages with where I am in the graph.

One other thing that occurred to me is that some of the large graphs I’m seeing are due to inlining across ObjC methods:

	- (BOOL)inner:(NSError **)outError; {…}
	- (BOOL)outer:(NSError **)outError; {
		return [self inner: outError];
	}

Here I’ll get something like:

begin function
	begin call
		begin function
			…
		end function
	end call
	…
end function

but I don’t need this sort of inlining for my checker. When processing -outer: I can assume that the call to -inner: does the right thing (writes to outError if its result is null, and leaves it undefined if it is non-null), and then -inner: can be independently checked.

But, if a method calls a block literal, I do need to let the inner function be processed. I haven’t yet arrived at a way using generateSink() that doesn’t just end the whole checking pass — is there a way to conditionally stop inline checking that I can use here?

void NSErrorWriteChecker::checkBeginFunction(CheckerContext &C) const {

  if (!C.inTopFrame()) {
    const LocationContext *LocCtxt = C.getLocationContext();
    if (dyn_cast<BlockDecl>(LocCtxt->getDecl()) == NULL) {
      // ???
      return;
    }
  }

  …
}

Thanks!

-Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180427/08e6ee4b/attachment.html>


More information about the cfe-dev mailing list