[cfe-dev] scan-build in python

Tue Jun 24 11:35:22 PDT 2014

On Tue, Jun 24, 2014 at 11:50 AM, Laszlo Nagy <
rizsotto.mailinglist at gmail.com> wrote:

> 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.
>

It isn't even really CPS since e.g. in arch_loop the "continuation" is
called in a loop, which means it isn't really a continuation; similarly in
set_analyzer_output, where you call the "continuation" from within a scope.
It just seems to correspond to some abstract notion of "a function that
parametrizes the behavior in some unspecified way". I'm not really sure
what to call it.

I do like how the "CPS" shows the major functional dependencies between the
functions in an up-front way.

I also like the precondition checking. Although it is a massive misnomer
because the cps decorator has nothing to do with CPS. All it does is insert
a call to the precondition check. So rename the cps function to
required_opts or whatever.

For clarity, I recommend defaulting the "continuation" parameter to the
name of the function that it is when the program runs (not while testing).
E.g.

...
def arch_loop(opts, files_loop=files_loop):
    ...

Then you can avoid that dance in run() and instead just call into the
top-level function.

-- Sean Silva

>
> - 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
>>>
>>
>>
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140624/d9bbfa4c/attachment.html>