<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 25, 2016, at 8:30 AM, Alexander Kornienko <<a href="mailto:alexfh@google.com" class="">alexfh@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">(having dug the e-mail from the bottom of my inbox)<div class=""><br class=""></div><div class="">I certainly like the idea of having an open-source web-based results browser for clang-tidy and clang static analyzer results. I like the features of CodeChecker (issue browsing, suppression, diffs). And I can suggest more potentially useful features like:</div><div class=""> * code-centric browsing of the issues (with directory view showing aggregate numbers of issues in each file/subdirectory and a file view showing all issues in the file in a compact form - without execution paths);</div><div class=""> * an easy way to apply fixes for a subset of issues in a file / directory.</div><div class=""><br class=""></div><div class="">I'm not sure though, if integrating CodeChecker source code to the LLVM project brings a lot of benefits to the CodeChecker developers and/or users. I don't have any objections, I just don't understand at this point, what are you expecting to achieve by moving the code to LLVM.</div><div class=""><div class="gmail_extra"><br class=""></div></div></div></div></blockquote><br class=""><div>The benefit to the CodeChecker team is that they will gain more visibility (both in terms of users and fellow developers).</div><div>The benefit to LLVM is that we could gain a much better issue viewing and triaging tool than what we have now. Ex: my hope is that CodeChecker would replace scan-view.</div><div><br class=""></div><div>Anna.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 4, 2016 at 1:10 PM, György Orbán <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br class="">
<br class="">
We started to restructure and cleanup our source code for a better integration with the current lit testing environment in llvm/clang.<br class="">
After we are done we can start to merge the source in.<span class=""><br class="">
<br class="">
On 03/02/2016 06:42 PM, Anna Zaks wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Adding CodeChecker infrastructure would be very valuable to those who use clang for bug finding. It provides a single place to view the bugs reported by different tools such as the static analyzer and clang-tidy. The ability to track bugs over time and cutting a baseline so that only the new bugs are reported is important for large projects that cannot address all of the issues at once.<br class="">
<br class="">
Let’s proceed with merging it in. Please, split commits into incremental logical chunks. (<a href="http://llvm.org/docs/DeveloperPolicy.html#incremental-development" rel="noreferrer" target="_blank" class="">http://llvm.org/docs/DeveloperPolicy.html#incremental-development</a>)<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Feb 23, 2016, at 2:10 AM, György Orbán via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">
<br class="">
Hi,<br class="">
<br class="">
We would like to add CodeChecker (<a href="https://github.com/Ericsson/codechecker" rel="noreferrer" target="_blank" class="">https://github.com/Ericsson/codechecker</a>) analyzer infrastructure.<br class="">
<br class="">
This is an alternative tool to scan-build with extended functionality.<br class="">
Some of the main features are: track issues over time, suppress false positives, detect new issues by comparing multiple analyzer run results,<br class="">
view and compare results in a web browser or in the command line. A more detailed feature list can be found below (*).<br class="">
The analyzer infrastructure is built in a way that integrating a new analyzer can be easily done.<br class="">
We are developing a tool which can be used easily by the developers or by automated continuous integration tools and view the results from multiple analyzers in a common way.<br class="">
We think it would serve as a good base for displaying and tracking bugs that can be detected by the other clang tools such as clang-tidy which is already supported.<br class="">
<br class="">
For example, you can find the analysis results of the LLVM code 3.6.2 and 3.7.1 here: <a href="http://modelserver.inf.elte.hu:5000/" rel="noreferrer" target="_blank" class="">http://modelserver.inf.elte.hu:5000</a><br class="">
<br class="">
Main questions to the community:<br class="">
0. Does the Clang community like the idea?<br class="">
1. CodeChecker has some 3rd party dependencies see below (**), are they acceptable?<br class="">
2. Is the community satisfied with the CodeChecker name?<br class="">
</blockquote>
Unless the name is a blocker on your side, I’d like to discuss it later once we see what the interface looks like. Frankly, I am not a fan of this name sine it’s very ambiguous.<br class="">
</blockquote></span>
I do not think it is a blocker, we can discuss it later.<span class=""><br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Integration plan:<br class="">
0. CodeChecker should use scan-build.py (OSX support) to generate the compilation database instead of the current LD_PRELOAD technique<br class="">
</blockquote></blockquote></span>
Should we implement this feature (with scan-build.py intercept) before we merge our code base or after?<div class=""><div class="h5"><br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Migrate CodeChecker testing infrastructure to the current LLVM testing infrastructure<br class="">
<br class="">
(*) Most notably it extends the current tool set with the following features:<br class="">
- stores the result of multiple large analysis run results efficiently (opposed to scan-build/scan-view static htmls)<br class="">
- run multiple analyzers, currently Clang Static Analyzer and Clang-Tidy is supported<br class="">
- dynamic web based defect viewer (instead of static html)<br class="">
- a SQLite/PostgreSQL based defect storage & management (both are optional, results can be shown on standard output in quickcheck mode)<br class="">
- update analyzer results only for modified files (depends on the build system)<br class="">
- compare analysis results (new/resolved/unresolved bugs compared to a baseline)<br class="">
- filter analysis results (checker name, severity, source file name ...)<br class="">
- skip analysis in specific source directories if required<br class="">
- suppression of false positives (in config file or in the source)<br class="">
- Thrift API based server-client model for storing bugs and viewing results.<br class="">
- It is possible to connect multiple bug viewers. Currently a web-based viewer and a command line viewer are provided.<br class="">
(command line client is the recommended way to connect into Continuous Integration loops)<br class="">
<br class="">
Command line examples of usage can be found here: <a href="https://github.com/Ericsson/codechecker/blob/master/docs/usage.md" rel="noreferrer" target="_blank" class="">https://github.com/Ericsson/codechecker/blob/master/docs/usage.md</a><br class="">
<br class="">
CodeChecker supports multiple use cases:<br class="">
- Small projects/several source files (quick feedback)<br class="">
No database is used, analysis results are shown in on the command line only<br class="">
- Medium size projects (~500 files)<br class="">
Results are stored in SQLite/PostgreSQL database and can be viewed from command line or web viewer clients<br class="">
- Large size projects (>500 files)<br class="">
Results are stored in PostgreSQL database and can be viewed from command line or web viewer clients<br class="">
<br class="">
There are currently discussions about analyzer tool support in multiple email threads:<br class="">
<br class="">
<a href="http://clang-developers.42468.n3.nabble.com/Idea-for-better-invoking-static-analysis-via-command-line-td4049670.html" rel="noreferrer" target="_blank" class="">http://clang-developers.42468.n3.nabble.com/Idea-for-better-invoking-static-analysis-via-command-line-td4049670.html</a><br class="">
<a href="http://clang-developers.42468.n3.nabble.com/Proposal-Integrate-static-analysis-test-suites-td4048967.html" rel="noreferrer" target="_blank" class="">http://clang-developers.42468.n3.nabble.com/Proposal-Integrate-static-analysis-test-suites-td4048967.html</a><br class="">
<br class="">
CodeChecker provides solutions for many problems discussed there:<br class="">
<br class="">
- Problem: Different analyzers provide different output formats (Clang Static Analyzer provides plist/html/command line, Clang-tidy provides command line output only)<br class="">
Solution: With Codechecker analyzer results from multiple analyzers can be viewed in a common way for developers or other tools for further result processing.<br class="">
<br class="">
- Problem: CC environment variable overwriting by previous scan-build version (written in perl) is not always a good solution.<br class="">
Solution: Compilation database is generated by CodeChecker (currently using the LD_PRELOAD technique, later with scan-build.py for OSX support).<br class="">
<br class="">
- Problem: Analyzer has multiple command line arguments which could be changed by time, the end users should not be affected.<br class="">
Solution: CodeChecker hides the clang analyzer specific options from the user. Many options are preconfigured. But forwarding options without modifications to the analyzers is supported.<br class="">
<br class="">
- Problem: Understanding analyzer results might be harder if only command line results are available (currently generated static html sites do not scale and it is hard to manage).<br class="">
Solution: Analysis steps can be viewed in command line with quickcheck or in the web viewer (dynamically generated based on the database), which can help to understand the analysis results.<br class="">
<br class="">
(**) 3rd party dependencies for various features:<br class="">
- Python 2.7.5 (Python Software Foundation) - required to run CodeChecker<br class="">
- SQLAlchemy (MIT) - Python SQL toolkit and Object Relational Mapper, for supporting multiple database backends<br class="">
- Alembic (MIT) - required for database migration support which is only available for PostgreSQL database<br class="">
- pg8000 (BSD) or psycopg2 (LGPL) - at least one database connector is required for PostgreSQL database support (both are supported)<br class="">
</blockquote>
We should NOT include dependencies on LGPL!<br class="">
</blockquote></div></div>
This is an optional runtime dependency (it is not included), we do not require it, we just support it at runtime if available at the host machine.<div class="HOEnZb"><div class="h5"><br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Thrift (Apache v2.0) - cross-language service building framework to handle data transfer for report storage and result viewer clients<br class="">
- Codemirror (MIT) - view source code in the browser<br class="">
- Jsplumb (community edition, MIT) - draw bug paths<br class="">
- Marked (BSD) - view documentation for checkers written in markdown (generated dynamically)<br class="">
- Dojotoolkit (BSD) - main framework for the web UI<br class="">
- Highlightjs (BSD) - required for highlighting the source code<br class="">
<br class="">
For further information check out our GitHub (<a href="https://github.com/Ericsson/codechecker" rel="noreferrer" target="_blank" class="">https://github.com/Ericsson/codechecker</a>) page.<br class="">
<br class="">
Best Regards,<br class="">
Gyorgy Orban<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</blockquote></blockquote>
Best Regards,<br class="">
Gyorgy Orban<br class="">
<br class="">
_______________________________________________<br class="">
cfe-dev mailing list<br class="">
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
</div></div></blockquote></div><br class=""></div></div></div>
</div></blockquote></div><br class=""></body></html>