[cfe-dev] scan-build in python

Tue Jun 24 10:50:26 PDT 2014

hi Jordan,

thanks for your answer.

- i might have been confusing with the README file. as you recognized the
'beye' does not build the project. that's right. but i do not propose to
replace 'scan-build' with 'beye' now. :) what i am offering here is the
'ccc-analyzer' and 'c++-analyzer'. (as far as i remember somebody else also
working on to rewrite 'scan-build' as part of SoC. that's why i not
invested much about that part.)

- will check about the style issue. (although it comply with PEP8. runs
continuously on every build.)

- about CPS (continuation-passing style). i think really it makes easier to
test the parts. if you tell me which part you find difficult to read, i
would try to simplify it more.

- about the tests. i will work on to rewrite them based on 'unittest'
instead of 'nose'. so, testing won't need external dependencies either.

- about 'parser_reject' reports. it does report when Clang exit with non
zero exit code. (the original scripts are reports: 'crash', 'other_error',
'parser_reject' and 'attribute_ignored'. the 'attribute_ignored' guarded
with a if condition which will never be true, the 'parser_reject' was
controlled by some variable which is assigned to false and never changed.)
so, broken compilation report are generated. those are the 'crash' or
'other_error' depends on the exit code.

- about the link options: can you say if i run something like 'clang test.c
-o a.out -lmylib -L..' this is linking and not compilation. the '-lmylib
-L..' goes to link options. but then i run the analyzer as 'clang --analyze
test.c ...' without the link options it will works just fine. won't it?
analyzer does not execute the link phase, does it?

thanks again your feedback. i will fix these issues and come back. enjoy
your vacation!

regards,
Laszlo

On Tue, Jun 24, 2014 at 6:36 PM, Jordan Rose <jordan_rose at apple.com> wrote:

> Ah, I see it's not actually building the project, just using a compilation
> database. I don't think that covers all the existing uses of scan-build,
> though, so I'm not sure that's good enough. (Consider cases where some of
> the source files are generated. The Xcode project thing is another issue
> entirely, but that uses a separate code path with modern Xcodes anyway.)
>
> Jordan
>
>
> On Jun 24, 2014, at 9:32 , Jordan Rose <jordan_rose at apple.com> wrote:
>
> Wow, nice work!
>
> I'm a bit concerned about this note:
>
>   - does not generate parser reject report, since analyzer does not report
> it;
>
>
> IIRC this happens when the analyzer *crashes* for some reason. I can't
> remember what happens if the file merely fails to compile, but you can test
> the crash case with "#pragma clang __debug crash".
>
> I would guess we collect link options because $CC or $CXX is often used
> for linking as well as building—remember that scan-build actually builds a
> project in addition to analyzing it. I'm not sure how we detect that,
> though, or if it's still necessary.
>
> And sorry for completely missing the -isysroot question. I agree, checking
> that explicitly seems unnecessary.
>
> I'm on vacation for the rest of the week, so I wouldn't be able to get
> back to you right away. Anna and Ted probably need to weigh in on if we
> want to take this into Clang proper (and we'd have to test it on OS X,
> including Xcode integration). If so, then yes, we would want to use a
> non-external unit test format. I've never worked with them, but it looks
> like we have tests for the Python bindings to libclang in
> bindings/python/tests.
>
> One thing I am a bit concerned about is complexity—not that the old code
> was simple, but some of analyzer.py seems rather opaque. (Does the CPS
> model really help that much?) The style also doesn't always seem consistent
> throughout the code (spaces around assignment operators was the main thing
> that jumped out at me).
>
> But overall, nice work, and I hope I or Anna gets the chance to try it out
> soon.
> Jordan
>
>
> On Jun 23, 2014, at 6:30 , 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/20140624/064943ae/attachment.html>