<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 24, 2014 at 11:50 AM, Laszlo Nagy <span dir="ltr"><<a href="mailto:rizsotto.mailinglist@gmail.com" target="_blank">rizsotto.mailinglist@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">hi Jordan,<div><br></div><div>thanks for your answer.</div><div><br></div><div>- 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.)</div>
<div><br></div><div>- will check about the style issue. (although it comply with PEP8. runs continuously on every build.)</div><div><br></div><div>- 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.</div>
</div></blockquote><div><br>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.<br><br><div>I do like how the "CPS" shows the major functional dependencies
between the functions in an up-front way.<br><br>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.<br><br>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.<br><br></div><div>...<br></div><div>def arch_loop(opts, files_loop=files_loop):<br> ...<br><br></div><div>Then you can avoid that dance in run() and instead just call into the top-level function.<br></div>
</div><div><br></div><div>-- Sean Silva<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div><br></div><div>- about the tests. i will work on to rewrite them based on 'unittest' instead of 'nose'. so, testing won't need external dependencies either.</div><div><br></div><div>- 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.</div>
<div><br></div><div>- 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?</div>
<div><br></div><div>thanks again your feedback. i will fix these issues and come back. enjoy your vacation!</div><div><br></div><div>regards,</div><div>Laszlo</div></div><div class=""><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">
On Tue, Jun 24, 2014 at 6:36 PM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div>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.)</div>
<span><font color="#888888"><div><br></div><div>Jordan</div></font></span><div><div><div><br></div><br><div><div>On Jun 24, 2014, at 9:32 , Jordan Rose <<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="word-wrap:break-word"><div>Wow, nice work!</div><div><br></div><div>I'm a bit concerned about this note:</div><div><br></div><div><div class="gmail_extra"><blockquote type="cite">
- does not generate parser reject report, since analyzer does not report it;</blockquote></div></div><div><br></div><div>IIRC this happens when the analyzer <i>crashes</i> 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".</div>
<div><br></div><div>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.</div>
<div><br></div><div>And sorry for completely missing the -isysroot question. I agree, checking that explicitly seems unnecessary.</div><div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>But overall, nice work, and I hope I or Anna gets the chance to try it out soon.</div><div>Jordan</div><div><br></div><br><div><div>On Jun 23, 2014, at 6:30 , Laszlo Nagy <<a href="mailto:rizsotto.mailinglist@gmail.com" target="_blank">rizsotto.mailinglist@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">hi there,<br><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">the current version available from here <<a href="https://github.com/rizsotto/Beye" target="_blank">https://github.com/rizsotto/Beye</a>><br></div><div class="gmail_extra">
<br></div><div class="gmail_extra">- it works, tested on python 2.6, 2.7, 3.x,</div><div class="gmail_extra">- it has no dependencies other than standard python modules,</div><div class="gmail_extra">- it differs from the current perl implementation in functionality,</div>
<div class="gmail_extra"> - does not generate not-used-attribute files, since analyzer does not report it;</div><div class="gmail_extra"> - does not generate parser reject report, since analyzer does not report it;</div>
<div class="gmail_extra"> - does not check '-isysroot' uniqness;</div><div class="gmail_extra"> - does execute 'clang' binary only if it needed (one time less than current perl);</div><div class="gmail_extra">
- does not copy pre-compiled header (.ghc) files into report directory;</div><div class="gmail_extra">- it works together with current 'scan-build',<br></div><div class="gmail_extra">- it was tested only on Linux.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">is it something that i need to fix or implement?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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?</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">regards,</div><div class="gmail_extra">Laszlo</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Oct 21, 2013 at 12:47 PM, Laszlo Nagy <span dir="ltr"><<a href="mailto:rizsotto.mailinglist@gmail.com" target="_blank">rizsotto.mailinglist@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">hi there,<br>
<br>
started to write a python script around Clang's static analyzer.<br>
mainly because found difficult to use the `scan-build` script. wanted<br>
to run against a compilation database instead of intercept the<br>
compiler calls. but would like to preserve the current usage as<br>
well... then at the same time, saw this page<br>
<<a href="http://clang-analyzer.llvm.org/open_projects.html" target="_blank">http://clang-analyzer.llvm.org/open_projects.html</a>> which suggest the<br>
rewrite as well. so, it might be a perfect match! ;)<br>
<br>
and as i try to copy the functionality of the `ccc-analyze` and<br>
`scan-build` scripts, discovered few minor bugs. (or they are not<br>
bugs, and i'm the one who can't read perl well.)<br>
<br>
now i'm looking for a person i can ask about these scripts.<br>
<br>
regards,<br>
Laszlo<br>
</blockquote></div><br></div></div>
</blockquote></div><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>