[cfe-dev] scan-build in python

Wed Jun 25 02:47:12 PDT 2014

thanks Sean for your feedback... will do the defaulting the "continuation"
parameter. i think it simplifies the code and make it more readable...
about the CPS name: i also recognized that it is not a clear CPS. asked
people nearby me and their suggestion was, that even it is not a CPS, but
that's the closest to it. and to hint the reader to understand how it
works, might be a good idea to misuse this word. :) would glad to rename,
but to what? i was thinking about: 'cpsl' (CPS like) or 'mcps' (maybe CPS),
but 'require' looks the best... thanks again for your time!

regards,
Laszlo

On Tue, Jun 24, 2014 at 8:35 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
>
> 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/20140625/85a9699b/attachment.html>