[cfe-dev] clang --analyze limitations

[Ted Kremenek]

Jack,

Doug's answers are spot on.  Part of this behavior is architectural, but you really should think of the analyzer as a separate tool from the compiler.  They just happen to (currently) use the same high level driver.  There is no guarantee that as the analyzer evolves that coupling static analysis with ordinary compilation would be the ideal model.  A plug-in model as Doug suggests would provide the flexibility to possibly do what you suggest, but also possibly run the analyzer in different ways.

On Jun 23, 2011, at 11:51 AM, Douglas Gregor <dgregor at apple.com> wrote:

> 
> On Jun 23, 2011, at 10:57 AM, Jack Howarth wrote:
> 
>>  Is there a particular reason why the clang --analyze feature was designed
>> to short-circuit compilations?
> 
> Just because it needs only a -fsyntax-check of the code, and the analyzer was useful long before Clang was useful for generating code. Plus, it's fairly common for people to use their normal compiler for building, but toss in Clang's static analyzer to find more bugs as they build.
> 
>> Currently it appears that 'clang --analyze' only
>> calls the static analyzer which seems unnecessarily limiting. If clang were to
>> call the static analyzer and then proceed with the normal compilation, this
>> feature would be much easier to use since simply adding --analyze to the compile
>> flags would allow a complete build to be quickly run through the static analyzer
>> as part of the normal build.
> 
> In the grand scheme of things, we'd love for the static analyzer to simply become a plug-in that can get run during a normal "build", regardless of whether that build is just a syntax-check (as we do now) or a build that generates object code.
> 
>    - Doug
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev