[cfe-dev] scan-build in python

Wed Jun 25 09:25:41 PDT 2014

On Wed, Jun 25, 2014 at 3:47 AM, Laszlo Nagy <rizsotto.mailinglist at gmail.com
> wrote:

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

It seems like it could be considered a form of dependency injection.

-- Sean Silva

> 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/40ff4f4d/attachment.html>