[Clang Static Analyzer] Preliminary patch for checkInitialState

[Jordan Rose]

On Dec 17, 2013, at 7:39 , Gabor Kozar <kozargabor at gmail.com> wrote: 
> I think a NULL initial state means a checker has decided not to analyze
> this function. Weird and unlikely, but possible. (For example, it allows
> us to move the -analyze-function option into a checker.)
>  
> Allowing a checker to make this decision on behalf of all the other checkers... I'm not absolutely certain I like that idea.
> It would indeed allow -analyze-function to become a checker, but I would consider that a hack: conceptually, I wouldn't consider this the job of a checker.
>  
> Besides -analyze-function, what would this enable? The only other thing I can think of is forcing the analyzer off code paths that are somehow known to the checker to be impossible. (I'm talking about allowing a checker to set a NULL state in general, not just in checkInitialState). That might be practical, I can imagine some uses, but it would also require considerably more effort than this.
>  
> I'll think some more about this, but for the time being I would disallow NULLs from checkInitialState.
It's more just that banning NULL seems like extra work that's inconsistent with most of the other checkers that return a single ProgramState.

Another option would be to allow checkers to start multiple states with addTransition. In that case, a checker could deliberately, say, test a function with various sensible inputs, rather than purely unconstrained ones.

> I'm not sold on this one yet. I mean, I get the idea, but it again seems
> like something where we want a nicer interface than just "FunctionDecl"
> (and at the very least need to handle ObjCMethodDecl as well). But we can
> discuss this later.
>  
> Also taking ObjCMethodDecl and BlockDecl into consideration, I'd say lets create an EntryPointInfo class, that would basically just wrap a PointerUnion3 (as an internal implementation detail), but would provide more straightforward accessor methods like getDecl, getFunctionDecl, getBlockDecl, as well as a get<T> and is<T>. This could also be generalized and put to use in checkInitialState, and even in CallEvent - I believe all we have right now is a const Decl* getDecl() there.
> What do you think?
CallEvent's getDecl is overridden to return more specific Decls in its subclasses, but for checkInitialState EntryPointInfo seems like a good idea. We may end up wanting to put other things in there as well.

> Finally, style notes (guessing this comes from bouncing between projects):
>  
> Yeah, in general, I tried to use the style I saw in the surrounding code, but I did not really pay attention to this. Will definitely fix it, thanks for pointing it out.
> At work, we're using clang-format to take care of these issues for us. I guess I can also set it up for when I'm working on Clang. You're using the LLVM style, right?

Yes. We're not actively reformatting existing code, but new code should pretty much just follow the LLVM style.

Thanks!
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131218/0a709293/attachment.html>