[cfe-dev] scan-build in python

[Laszlo Nagy]

hi,

based on your feedbacks, made several changes to the python implementation.
one of the tasks i'm struggle with is to add more comment. :) and there is
one major thing which i do in the python script, because the perl script
does the same. although i don't see the reason why it is like this.

when analyzer is executed it is done in two steps.

|  $ clang -### --analyze ...the.rest.of.the.command...
|  ...
|  "clang" "-cc1" ...some.more.parameters...
|  $ "clang" "-cc1" ...some.more.parameters...

so, we ask clang to print how to run the analyzer, and then we execute that
command which was emitted. although it would be the very same to do this

|  $ clang --analyze ...the.rest.of.the.command...

can somebody tell me what is the reason behind this indirection?

thanks in advance,
Laszlo


On Mon, Jun 23, 2014 at 3:30 PM, Laszlo Nagy <rizsotto.mailinglist at gmail.com
> wrote:

> hi there,
>
> during the last half year i did re-implemented the `ccc-analyzer` and
> `c++-analyzer` perl scripts in python. to make it into the Clang code base
> i would like to know what would be the acceptance criteria for such scripts.
>
> the current version available from here <https://github.com/rizsotto/Beye>
>
> - it works, tested on python 2.6, 2.7, 3.x,
> - it has no dependencies other than standard python modules,
> - it differs from the current perl implementation in functionality,
>   - does not generate not-used-attribute files, since analyzer does not
> report it;
>   - does not generate parser reject report, since analyzer does not report
> it;
>   - does not check '-isysroot' uniqness;
>   - does execute 'clang' binary only if it needed (one time less than
> current perl);
>   - does not copy pre-compiled header (.ghc) files into report directory;
> - it works together with current 'scan-build',
> - it was tested only on Linux.
>
> is it something that i need to fix or implement?
>
> what format would you like to get it? i'm thinking to create a python
> package out of it. (currently it's non python package conform.) but
> recently took a look on llvm-lit. which might be a good pattern to follow.
> (they keep python module structure, but CMake also plays role to install
> those scripts.)
>
> currently unit tests are written in 'nose'. (which is non standard python
> module.) shall i rewrote it into the standard python unit test? is there
> any example inside Clang code base? (python script with tests around it.)
>
> and one more question: current implementation is collecting the compiler
> and link options into separate array. but the link options are never used.
> can i stop collecting those or shall fix other parts of the code?
>
> regards,
> Laszlo
>
>
> On Mon, Oct 21, 2013 at 12:47 PM, Laszlo Nagy <
> rizsotto.mailinglist at gmail.com> wrote:
>
>> hi there,
>>
>> started to write a python script around Clang's static analyzer.
>> mainly because found difficult to use the `scan-build` script. wanted
>> to run against a compilation database instead of intercept the
>> compiler calls. but would like to preserve the current usage as
>> well... then at the same time, saw this page
>> <http://clang-analyzer.llvm.org/open_projects.html> which suggest the
>> rewrite as well. so, it might be a perfect match! ;)
>>
>> and as i try to copy the functionality of the `ccc-analyze` and
>> `scan-build` scripts, discovered few minor bugs. (or they are not
>> bugs, and i'm the one who can't read perl well.)
>>
>> now i'm looking for a person i can ask about these scripts.
>>
>> regards,
>> Laszlo
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140627/b4fff614/attachment.html>