<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=gb2312">

<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>

</head>

<body dir="ltr">

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Hi Valeriy,</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

I just can second the opinions that Kristof and Gábor had said previously, this is indeed a great initiative!</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

About the docker images, perhaps we need a hierarchy of images. A base image that makes it possible to analyze locally (e.g. on a laptop), an other image for the build bots (jenkins) that builds on top of the base image.</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<br>

</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

Note, that we have a <a href="http://codechecker-buildbot.eastus.cloudapp.azure.com:8080/job/ctu_pipeline_clang-master-monorepo/" title="http://codechecker-buildbot.eastus.cloudapp.azure.com:8080/job/ctu_pipeline_clang-master-monorepo/">

publicly available build bot</a> that analyses many open source projects:</div>

<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">

<span>- Tmux (C)</span>

<div>- Curl (C)</div>

<div>- Redis (C)</div>

<div>- Xerces (C++14)</div>

<div>- Bitcoin (C++11)</div>

<div>- Protobuf (C++11/C++14)</div>

<div>But the focus is mostly on CTU. See, <a href="http://lists.llvm.org/pipermail/cfe-dev/2019-November/063945.html" style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">http://lists.llvm.org/pipermail/cfe-dev/2019-November/063945.html</a> for

 more details.</div>

<div>This build bot uses csa-testbanch and CodeChecker.</div>

<div>In the past this bot indicated a crash introduced by a change in the CSA about CXXInheritedConstructors, first I thought we have a CTU related error but then it turned out it was not. So, yes, we need build bots that do analyze opensource projects.</div>

<div><br>

</div>

<div>Thanks,</div>

<div>Gabor</div>

<div><br>

</div>

</div>

<div id="appendonsend"></div>

<hr style="display:inline-block;width:98%" tabindex="-1">

<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Valeriy Savchenko <vsavchenko@apple.com><br>

<b>Sent:</b> Monday, June 15, 2020 3:05 PM<br>

<b>To:</b> Artem Dergachev <noqnoqneo@gmail.com><br>

<b>Cc:</b> Kristóf Umann <dkszelethus@gmail.com>; Gábor Horváth <xazax.hun@gmail.com>; Gábor Márton <gabor.marton@ericsson.com>; cfe-dev <cfe-dev@lists.llvm.org>; Balázs Kéri <Balazs.Keri@ericsson.com><br>

<b>Subject:</b> Re: [cfe-dev] [analyzer] Regression testing for the static analyzer</font>

<div> </div>

</div>

<div class="" style="word-wrap:break-word; line-break:after-white-space">First of all, thank you a lot for engaging in this conversation, sharing your ideas, and, of course, for your kind words :-)

<div class=""><br class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<div class="">Huge +1. Actually, I'd be even glad to see more extremes like running the analyzer multiple times making sure that the number of exploded graphs and other statistics are stable to avoid introducing non-deterministic behavior. </div>

</div>

</div>

</blockquote>

</div>

</blockquote>

<p class="">This one's not just about nondeterminism, it's also about reproducibility across machines with different systems and system headers. Like you'll be able to say "hey we broke something in our docker tests, take a look" and you'll no longer need to

 extract and send to me a preprocessed file. That's a lot if we try to collectively keep an eye on the effects of our changes on a single benchmark (or even if you have your own benchmark it's easy to share the project config because it's basically just a link

 to the project on github).</p>

<div class=""></div>

</blockquote>

<div class="">Yes, and yes!  I thought about running the analyzer multiple times on one project for benchmarking.  In that mode we can also check for variations in stats between seemingly identical runs.</div>

<div class="">Sharing is probably the best part of this approach.</div>

<div class=""><br class="">

</div>

<div class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<div class="">Dependencies are the bane of C++ at the moment. I'd love to see some other solutions for this problem. Some of them coming to my mind:</div>

<div class="">* Piggy backing on the source repositories of linux distributions. We could easily install all the build dependencies using the package manager automatically. The user would only need to specify the name of the source package, the rest could be

 automated without having to manually search for the names of the dependent packages.</div>

<div class="">* Supporting C++ package managers. There is Conan, vcpkg and some CMake based. We could use a base docker image that already has these installed.</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

</blockquote>

<br class="">

</div>

<div class="">Unfortunately, package managers could not be a solution across different platforms if we need reproducible results, one of the Conan’s main features is downloading packages appropriate for the current user setup pretty seemingly and consistently

 across different setups.  However it means that they are still different.</div>

<div class=""><br class="">

</div>

<div class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<div class="">We could use a base docker image that already has these installed.</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

</blockquote>

<br class="">

This is probably a good solution, but I didn’t have problem to build natively in docker so far.</div>

<div class=""><br class="">

</div>

<div class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<div class="">While I think this is a great idea we also should not forget that the tested projects should exercise the right parts of the analyzer. For instance, a patch adding exception support should be tested on projects that are using exceptions extensively.

 Having a static set of projects will not solve this problem. Nevertheless, this is something that is far less important to solve. First, we need something that is very close to what you proposed.</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

</blockquote>

<br class="">

</div>

<div class="">I do agree, it should be definitely on a roadmap.  I also planned to have a tag system for projects, like “tiny”, “math”, “C++14”, “web”, and so on.  It is not exactly what you have in mind, but I think it could be a good first step in that direction.</div>

<div class=""><br class="">

</div>

<div class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<div class="">How long do we want to retain Python 2 compatibility? I'm all in favor of not supporting it for long (or at all).</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

<p class="">As far as i understand we've still not "officially" transitioned to python3 in llvm. I don't think it actually matters for these scripts; it's not like they're run every day on an ancient buildbot that still doesn't have python3 (in fact as of now

 i don't think anybody uses them at all except us) but it sounds like in any case the only script that really needs to be python2 up to all possible formal requirements is `SATest.py` itself which is a trivial wrapper that parses some arguments and forwards

 them into docker; for everything else there's docker and you don't care what's within it.</p>

</blockquote>

</div>

<div class="">So, yes, as Artem said, SATest.py is the only script that is compatible with both versions.  All other parts of the system had been migrated to Python 3.</div>

<div class=""><br class="">

</div>

<div class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<div class="">

<div class="">I think one very important feature is to collect/compare not only the analysis results but more fine-grained information like the statistics emitted by the analyzer (number of refuted reports in case of refutation, number of exploded nodes, and

 so on). <br class="">

</div>

<div class="">It would be nice to be able to retrieve anything crash-related like call stacks and have an easy way to ssh into the docker image to debug the crash within the image. <br class="">

</div>

<div class="">Also, the csa-testbench has a feature to define regular expressions and collect the matching lines of the analyzer output. This can be useful to count/collect log messages.</div>

</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

</blockquote>

<br class="">

</div>

<div class="">The usability of this system is probably the main point for me, so the ease of debugging should be the priority.  I already introduced a `—shell` option that provides an easy way to ssh into a docker without thinking too much about docker nature

 of things (if container is not running and how to clean it up afterwards).  And I believe pattern-matching certain erroneous situations and making a short summary out of those can be a really good feature.</div>

<div class=""><br class="">

</div>

<div class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<div class="">While I see the value of having a minimal interface I wonder if it will be a bit limiting to the power users in the end (see extracting statistics and logs based on regexp)., </div>

</div>

</div>

</blockquote>

</div>

</blockquote>

<p class="">I think it's totally worth it to have both. When a newcomer tries to test their first checker there's nothing better than a simple one-liner that we can tell them to run. But on the other hand having fine-grained commands for controlling every step

 of the process is absolutely empowering and not going anywhere.</p>

<div class=""></div>

</blockquote>

<div class="">It’s exactly right.  I believe that with a set of very reasonable defaults it can be achieved.  All additional tweaking should be probably categorized and put into README.</div>

</div>

<div class=""><br class="">

</div>

<div class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div dir="ltr" class="">

<div class="">While I do my best to contribute non-breaking code, the tedious process of jumping on the company VPN, finding the appropriate server that isn't under heavy load to run an analysis that is thorough enough sometimes leaves me to commit seemingly

 miscellaneous patches after only running check-clang-analysis, which on occasions comes to bite back.</div>

</div>

</blockquote>

</blockquote>

<br class="">

</div>

<div class="">Yeah, it’s hard to predict sometimes what can be broken on a real code.  And if it is pretty scary to make changes for experienced users, what can be said about newcomers.</div>

<div class=""><br class="">

</div>

<div class="">

<blockquote type="cite" class="">

<blockquote type="cite" class="">

<div dir="ltr" class="">

<div class="">side effects on other platforms</div>

</div>

</blockquote>

</blockquote>

<br class="">

</div>

<div class="">It is pretty hard to avoid those, I guess we’ll have to keep our separate CI setups for that, but at least we’ll be able to get rid of the majority of issues common across platforms.</div>

<div class=""><br class="">

</div>

<div>

<blockquote type="cite" class="">

<div class="">On 11 Jun 2020, at 20:50, Artem Dergachev via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div>

<br class="x_Apple-interchange-newline">

<div class="">

<div class="x_moz-cite-prefix" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="x_Apple-interchange-newline">

11.06.2020 8:13 PM, Kristóf Umann via cfe-dev пишет:<br class="">

</div>

<blockquote type="cite" class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; orphans:auto; text-align:start; text-indent:0px; text-transform:none; white-space:normal; widows:auto; word-spacing:0px; text-decoration:none">

<div dir="ltr" class="">+Ericssson gang<br class="">

<div class=""><br class="">

</div>

<div class="">Endre and Gábor Márton in particular worked a lot of builtbots (CTU related ones in particular), so I wouldn't risk summarizing our current stance/progress on this issue.</div>

<div class=""><br class="">

</div>

<div class="">What I will say however from my perspective is that I find committing stressful for all the reasons you mentioned. While I do my best to contribute non-breaking code, the tedious process of jumping on the company VPN, finding the appropriate server

 that isn't under heavy load to run an analysis that is thorough enough sometimes leaves me to commit seemingly miscellaneous patches after only running check-clang-analysis, which on occasions comes to bite back. Things like changes in the report count (in

 drastic cases changes in the bug reports themselves, such as new notes), side effects on other platforms, etc. makes this process really error prone as well, not to mention that its at the point where I'm just itching to commit and move on. While the responsibility

 of the committed or soon-to-be-commited code still falls on the contributor, the lack of builbots on a variety of platforms still makes this process very inconvenient and downright hostile to non-regulars. Not to mention the case where I fill the role of the

 reviewer.</div>

<div class=""><br class="">

</div>

<div class="">All in all, I really appreciate this project and agree strongly with your goals!</div>

</div>

<br class="">

<div class="x_gmail_quote">

<div dir="ltr" class="x_gmail_attr">On Thu, 11 Jun 2020 at 17:51, Gábor Horváth via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">

</div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div dir="ltr" class="">

<div class="">Hi!<br class="">

<br class="">

</div>

<div class="">I'm glad that someone picked this up. Making it easier to test the analyzer on real-world topics is an important task that can ultimately make it much easier to contribute to the analyzer.</div>

<div class="">See some of my comments inline.<br class="">

</div>

</div>

<br class="">

<div class="x_gmail_quote">

<div dir="ltr" class="x_gmail_attr">On Thu, 11 Jun 2020 at 16:23, Valeriy Savchenko via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">

</div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

Person has to find at least a couple of projects, build them natively, and check<br class="">

with the analyzer. ... It should be dead simple, maybe as simple as running<br class="">

`lit` tests.<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">While I think this is a great idea we also should not forget that the tested projects should exercise the right parts of the analyzer. For instance, a patch adding exception support should be tested on projects that are using exceptions extensively.

 Having a static set of projects will not solve this problem. Nevertheless, this is something that is far less important to solve. First, we need something that is very close to what you proposed.<br class="">

</div>

<div class=""> </div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

Another point that of interest, is reproducibility.<span class="x_Apple-converted-space"> </span><br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">Huge +1. Actually, I'd be even glad to see more extremes like running the analyzer multiple times making sure that the number of exploded graphs and other statistics are stable to avoid introducing non-deterministic behavior.<span class="x_Apple-converted-space"> </span><br class="">

</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="">

</p>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

This one's not just about nondeterminism, it's also about reproducibility across machines with different systems and system headers. Like you'll be able to say "hey we broke something in our docker tests, take a look" and you'll no longer need to extract and

 send to me a preprocessed file. That's a lot if we try to collectively keep an eye on the effects of our changes on a single benchmark (or even if you have your own benchmark it's easy to share the project config because it's basically just a link to the project

 on github).<br class="">

</p>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="">

</p>

<blockquote type="cite" class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; orphans:auto; text-align:start; text-indent:0px; text-transform:none; white-space:normal; widows:auto; word-spacing:0px; text-decoration:none">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

Short summary of what is there:<br class="">

 <span class="x_Apple-converted-space"> </span>* Info on 15 open-source projects to analyze, most of which are pretty small<br class="">

 <span class="x_Apple-converted-space"> </span>* Dockerfile with fixed versions of dependencies for these projects </blockquote>

<div class=""><br class="">

</div>

<div class="">Dependencies are the bane of C++ at the moment. I'd love to see some other solutions for this problem. Some of them coming to my mind:</div>

<div class="">* Piggy backing on the source repositories of linux distributions. We could easily install all the build dependencies using the package manager automatically. The user would only need to specify the name of the source package, the rest could be

 automated without having to manually search for the names of the dependent packages.</div>

<div class="">* Supporting C++ package managers. There is Conan, vcpkg and some CMake based. We could use a base docker image that already has these installed.</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="">

</p>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

Just curious, given that it's debian under the hood, can we replace our make scripts with "scan-build apt-build" or something like that?</p>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="">

</p>

<blockquote type="cite" class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; orphans:auto; text-align:start; text-indent:0px; text-transform:none; white-space:normal; widows:auto; word-spacing:0px; text-decoration:none">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

The system has two dependencies: python (2 or 3) and docker. <span class="x_Apple-converted-space"> </span><br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">How long do we want to retain Python 2 compatibility? I'm all in favor of not supporting it for long (or at all).<br class="">

</div>

<div class=""> <br class="">

</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="">

</p>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

As far as i understand we've still not "officially" transitioned to python3 in llvm. I don't think it actually matters for these scripts; it's not like they're run every day on an ancient buildbot that still doesn't have python3 (in fact as of now i don't think

 anybody uses them at all except us) but it sounds like in any case the only script that really needs to be python2 up to all possible formal requirements is `SATest.py` itself which is a trivial wrapper that parses some arguments and forwards them into docker;

 for everything else there's docker and you don't care what's within it.</p>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="">

</p>

<blockquote type="cite" class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; orphans:auto; text-align:start; text-indent:0px; text-transform:none; white-space:normal; widows:auto; word-spacing:0px; text-decoration:none">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

(I am not a `csa-testbench` user, so please correct me if I'm wrong here)<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">Your assessment is 100% correct here. We always wanted to add docker support and support for rebuilding source deb packages to solve most of the issues you mentioned.<span class="x_Apple-converted-space"> </span><br class="">

</div>

<div class=""> <br class="">

</div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

 <span class="x_Apple-converted-space"> </span>* I want it to cover all basic needs of the developer:<br class="">

     <span class="x_Apple-converted-space"> </span>- analyze a bunch of projects and show results<br class="">

     <span class="x_Apple-converted-space"> </span>- compare two given revisions<br class="">

     <span class="x_Apple-converted-space"> </span>- benchmark and compare performance<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">

<div class="">I think one very important feature is to collect/compare not only the analysis results but more fine-grained information like the statistics emitted by the analyzer (number of refuted reports in case of refutation, number of exploded nodes, and

 so on).<span class="x_Apple-converted-space"> </span><br class="">

</div>

<div class="">It would be nice to be able to retrieve anything crash-related like call stacks and have an easy way to ssh into the docker image to debug the crash within the image.<span class="x_Apple-converted-space"> </span><br class="">

</div>

<div class="">Also, the csa-testbench has a feature to define regular expressions and collect the matching lines of the analyzer output. This can be useful to count/collect log messages.<br class="">

</div>

</div>

<div class=""> </div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

 <span class="x_Apple-converted-space"> </span>* I want all commands to be as simple as possible, e.g.:<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">While I see the value of having a minimal interface I wonder if it will be a bit limiting to the power users in the end (see extracting statistics and logs based on regexp).,<span class="x_Apple-converted-space"> </span><br class="">

</div>

</div>

</div>

</blockquote>

</div>

</blockquote>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="">

</p>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

I think it's totally worth it to have both. When a newcomer tries to test their first checker there's nothing better than a simple one-liner that we can tell them to run. But on the other hand having fine-grained commands for controlling every step of the process

 is absolutely empowering and not going anywhere.</p>

<p class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<br class="">

</p>

<blockquote type="cite" class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; orphans:auto; text-align:start; text-indent:0px; text-transform:none; white-space:normal; widows:auto; word-spacing:0px; text-decoration:none">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<div dir="ltr" class="">

<div class="x_gmail_quote">

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

 <span class="x_Apple-converted-space"> </span>* Would you use a system like this?<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">In the case, it supports my needs, definitely. As you mentioned, there are multiple contenders here: csa-testbench and SATest. I do see why the testbench is not desirable (mainly because of the dependencies), but I wonder if it would make sense

 to have compatible configurations. I.e. one could copy and paste a project from one to the other have it working without any additional efforts.<span class="x_Apple-converted-space"> </span><br class="">

</div>

<div class=""> </div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

 <span class="x_Apple-converted-space"> </span>* Does the proposed solution seem reasonable in this situation?<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">Looks good to me.<span class="x_Apple-converted-space"> </span><br class="">

</div>

<div class=""> </div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

 <span class="x_Apple-converted-space"> </span>* What do you think about the directions?<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">+1<br class="">

</div>

<div class=""> </div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

 <span class="x_Apple-converted-space"> </span>* What other features do you want to see in the system?<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">See my other inlines above.<br class="">

</div>

<div class=""> </div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

 <span class="x_Apple-converted-space"> </span>* What are the priorities for the project and what is the minimal feature<br class="">

   <span class="x_Apple-converted-space"> </span>scope to start using it?<br class="">

</blockquote>

<div class=""><br class="">

</div>

<div class="">If we can run it reliably on big projects I'd say have a built bot as soon as possible (that only triggers when crashes are introduced). I think it could have prevented many errors.<span class="x_Apple-converted-space"> </span><br class="">

</div>

<div class=""> </div>

<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left-width:1px; border-left-style:solid; border-left-color:rgb(204,204,204); padding-left:1ex">

<br class="">

Thank you for taking your time and reading through this!<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="https://protect2.fireeye.com/v1/url?k=da2c2501-848c9f6f-da2c659a-86b1886cfa64-4c569fac4baa8db7&q=1&e=e451d795-7ecf-47e4-84dc-c7d3307fe668&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">

</blockquote>

</div>

</div>

_______________________________________________<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="https://protect2.fireeye.com/v1/url?k=38e3a122-66431b4c-38e3e1b9-86b1886cfa64-9f282f48421958f4&q=1&e=e451d795-7ecf-47e4-84dc-c7d3307fe668&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">

</blockquote>

</div>

<br class="">

<fieldset class="x_mimeAttachmentHeader"></fieldset>

<pre class="x_moz-quote-pre">_______________________________________________

cfe-dev mailing list

<a class="x_moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>

<a class="x_moz-txt-link-freetext" href="https://protect2.fireeye.com/v1/url?k=cc9c81c9-923c3ba7-cc9cc152-86b1886cfa64-3e6285006409def7&q=1&e=e451d795-7ecf-47e4-84dc-c7d3307fe668&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>

</pre>

</blockquote>

<span class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none; float:none; display:inline!important">_______________________________________________</span><br class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<span class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none; float:none; display:inline!important">cfe-dev

 mailing list</span><br class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<a href="mailto:cfe-dev@lists.llvm.org" class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; orphans:auto; text-align:start; text-indent:0px; text-transform:none; white-space:normal; widows:auto; word-spacing:0px">cfe-dev@lists.llvm.org</a><br class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; text-align:start; text-indent:0px; text-transform:none; white-space:normal; word-spacing:0px; text-decoration:none">

<a href="https://protect2.fireeye.com/v1/url?k=7e2d8b10-208d317e-7e2dcb8b-86b1886cfa64-ab579eb663068255&q=1&e=e451d795-7ecf-47e4-84dc-c7d3307fe668&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-dev" class="" style="font-family:Helvetica; font-size:12px; font-style:normal; font-variant-caps:normal; font-weight:normal; letter-spacing:normal; orphans:auto; text-align:start; text-indent:0px; text-transform:none; white-space:normal; widows:auto; word-spacing:0px">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></div>

</blockquote>

</div>

<br class="">

</div>

</div>

</body>

</html>