It has multi-language support - https://community.synopsys.com/s/question/0D53400003WcsSiCAJ/what-languages-are-supported-by-synopsys-static-analysis-coverity
Robert Dale On Wed, Mar 21, 2018 at 10:01 AM, Robert Dale <[email protected]> wrote: > Another option might be to use Coverity - https://scan.coverity.com/faq - > and run it in Travis CI > > Robert Dale > > On Wed, Mar 21, 2018 at 9:43 AM, Stephen Mallette <[email protected]> > wrote: > >> > I think any proposed changes would be separate PRs and reviewed on a >> case-by-case >> basis. >> >> yeah - i think if we want something like this the goal should first be to >> decide on a tool (i can't say that i agree with Roman that "running more >> tools is always better" btw). note i'm still saying, "if we want something >> like this" because while i'm not against it I'd like to be convinced that >> we need to worry about this now at this stage of TinkerPop's development. >> i'd have been more inclined to deal with this early on in TinkerPop's >> development rather than now. And, yes, also agree that i would like to see >> the tool in first and then each introduction of "rule" be a separate >> discussion and PR. >> >> > As for making it the default compiler, I think this would be a profile, >> disabled by default, at best at least until a time it can be massaged to >> where it works for this project. >> >> yeah....that might be a smart way to go >> >> > whether other static analysis tools would find most of the problems >> that >> such a compiler can find and also work with other languages than Java. >> >> very good thought. while the bulk of our code is java, we are far from a >> single language code base. if there is one tool that can give us some nice >> clean analysis across the entire code base, perhaps that's the best way to >> go (again, "if we want something like this"). >> >> >> >> >> On Tue, Mar 20, 2018 at 8:41 AM, Florian Hockmann <[email protected] >> > >> wrote: >> >> > In general, I am +1 on adding a static analysis tool to our tool chain. >> > I just wonder whether a Java compiler is the best choice for us right >> > now or whether other static analysis tools would find most of the >> > problems that such a compiler can find and also work with other >> > languages than Java. SonarQube[1] for example looks pretty nice. It also >> > supports Python, C#, and JavaScript and we can probably just integrate >> > it via GitHub to generate reports for the release branches and all PRs >> > where it would then add issues in the form of inline comments. >> > >> > [1] https://www.sonarqube.org/ >> > >> > Am 20.03.2018 um 03:42 schrieb Robert Dale: >> > > Some changes look good others look wrong evident by the failed >> builds. I >> > > think any proposed changes would be separate PRs and reviewed on a >> > > case-by-case basis. As for making it the default compiler, I think >> this >> > > would be a profile, disabled by default, at best at least until a >> time it >> > > can be massaged to where it works for this project. >> > > >> > > On Mon, Mar 19, 2018 at 14:59 Roman Leventov <[email protected]> >> > wrote: >> > > >> > >> See https://github.com/apache/tinkerpop/pull/819. >> > >> >> > >> 1) Are there any objections to using error-prone compiler instead of >> > >> OpenJDK's javac compiler? >> > >> 2) Stephen raised the question, that Tinkerpop project may better use >> > >> another static analysis tool instead of error-prone. I have to answer >> > that >> > >> no static analysis tool covers 100% of the errors found by any other >> > tool, >> > >> so running more tools is always better. >> > >> 3) Stephen raised the question, what checks should be enabled. I >> believe >> > >> this is out of scope of the PR ( >> > >> https://github.com/apache/tinkerpop/pull/819), >> > >> because it doesn't (and doesn't intent to) enable any more checks >> > beyond >> > >> the default (= minimal) set of error patterns. More checks may or may >> > not >> > >> be enabled in later PRs and that could be discussed separately. >> > >> >> > >> > >> > >> > >
