www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Static Analysis Tooling / Effective D

reply "Brian Schott" <briancschott gmail.com> writes:
I've checked in code to the DScanner project that gives it some 
basic static analysis capabilities. When run with the 
--styleCheck option, it will warn about a few things like empty 
declarations, implicit string concatenation, classes with 
lowercase_names, catching "Exception", and a few other things.

There's a small feature wishlist in the project's README, but I'd 
like to get some opinions from the newsgroup: What kinds of 
errors have you seen in your code that you think a static 
analysis tool could help with?
Jan 20 2014
next sibling parent "Suliman" <evermind live.ru> writes:
It would be perfect have plugin for any Text Editor like Sublime
Jan 20 2014
prev sibling next sibling parent "Volcz" <volcz kth.se> writes:
On Tuesday, 21 January 2014 at 04:34:57 UTC, Brian Schott wrote:
 I've checked in code to the DScanner project that gives it some 
 basic static analysis capabilities. When run with the 
 --styleCheck option, it will warn about a few things like empty 
 declarations, implicit string concatenation, classes with 
 lowercase_names, catching "Exception", and a few other things.

 There's a small feature wishlist in the project's README, but 
 I'd like to get some opinions from the newsgroup: What kinds of 
 errors have you seen in your code that you think a static 
 analysis tool could help with?

I don't have any D specific errors that I keep repeating. I use SonarQube at work with Java. Here is a list of some of the "rules" that I use: https://github.com/SonarSource/sonar-java/tree/master/java-checks/src/main/java/org/sonar/java/checks
Jan 20 2014
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/20/2014 8:34 PM, Brian Schott wrote:
 I've checked in code to the DScanner project that gives it some basic static
 analysis capabilities. When run with the --styleCheck option, it will warn
about
 a few things like empty declarations, implicit string concatenation, classes
 with lowercase_names, catching "Exception", and a few other things.

 There's a small feature wishlist in the project's README, but I'd like to get
 some opinions from the newsgroup: What kinds of errors have you seen in your
 code that you think a static analysis tool could help with?

Automated source code formatting would be nice (and it's not as easy as it looks).
Jan 21 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2014 12:54 AM, Dicebot wrote:
 On Tuesday, 21 January 2014 at 08:01:47 UTC, Walter Bright wrote:
 Automated source code formatting would be nice (and it's not as easy as it
 looks).

It has nothing to do with static analysis.

Coverity (a static analyzer) does checks based on whitespace indentation. It's not a great leap from there to just format it.
Jan 21 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Walter Bright"  wrote in message news:lbl9ha$i85$1 digitalmars.com...
 Automated source code formatting would be nice (and it's not as easy as it 
 looks).

That would be great, we could run it on the generated ddmd source and I wouldn't have to fix all the remaining formatting bugs!
Jan 21 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 21 January 2014 at 08:01:47 UTC, Walter Bright wrote:
 Automated source code formatting would be nice (and it's not as 
 easy as it looks).

It has nothing to do with static analysis.
Jan 21 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 21 January 2014 at 04:34:57 UTC, Brian Schott wrote:
 I've checked in code to the DScanner project that gives it some 
 basic static analysis capabilities. When run with the 
 --styleCheck option, it will warn about a few things like empty 
 declarations, implicit string concatenation, classes with 
 lowercase_names, catching "Exception", and a few other things.

 There's a small feature wishlist in the project's README, but 
 I'd like to get some opinions from the newsgroup: What kinds of 
 errors have you seen in your code that you think a static 
 analysis tool could help with?

I'd personally love to see most of existing DMD warnings moved to DScanner and, after it get some recognition, removed from compiler completely. That, of course, implies some way to tune output for specific project, supressing some of detection patterns. That reminds me about related topic - do we have any pragma / attribute reserved for external tools? So that one could, for example, disable analysis error for specific part of sourc code without disabling it globally?
Jan 21 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2014 12:58 AM, Dicebot wrote:
 That reminds me about related topic - do we have any pragma / attribute
reserved
 for external tools? So that one could, for example, disable analysis error for
 specific part of sourc code without disabling it globally?

Since we have user defined attributes, I don't see how anything further needs to be added to the language.
Jan 21 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-01-21 10:33, Dicebot wrote:

 See "reserved namespace" reference. It does not need any special support
 from the language itself but some support from spec that will ensure
 that those attributes won't conflict with user code and other tools will
 be helpful. Probably even in form of guideline, not a rule.

The answer to this is usually that each tool should use its own attributes and that fully qualified names should properly disambiguate the attributes. Although, in this case it might be asking a bit too much for a tool to be able to properly figure out fully qualified names of symbol names. -- /Jacob Carlborg
Jan 21 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2014 1:33 AM, Dicebot wrote:
 See "reserved namespace" reference. It does not need any special support from
 the language itself but some support from spec that will ensure that those
 attributes won't conflict with user code and other tools will be helpful.
 Probably even in form of guideline, not a rule.

This is quite overengineering to put such in the spec. coverity_warnings should do fine (i.e. prefix with your tool name). It's not any harder than coming up with names for your third party library.
Jan 21 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/21/2014 1:07 PM, Brian Schott wrote:
 On Tuesday, 21 January 2014 at 20:26:57 UTC, Walter Bright wrote:
  coverity_warnings

 should do fine (i.e. prefix with your tool name). It's not any harder than
 coming up with names for your third party library.

"test.d(10): Error: undefined identifier coverity_warnings" In order for this to work the analysis tool would have to distribute a .d or .di file that is imported by any module that needs to suppress warnings. Java has the SuppressWarnings annotation in the standard java.lang to avoid this.

The trouble is if you start doing that, you end up in an endless ratrace of adding ever more "standard" names. If you're going to use a static checker, it doesn't seem to me to be a big burden to provide an import for it.
Jan 21 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-01-21 22:07, Brian Schott wrote:

 "test.d(10): Error: undefined identifier coverity_warnings"

 In order for this to work the analysis tool would have to distribute a
 .d or .di file that is imported by any module that needs to suppress
 warnings. Java has the SuppressWarnings annotation in the standard
 java.lang to avoid this.

Or just use an ugly string: ("coverity_warnings") -- /Jacob Carlborg
Jan 22 2014
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 21 January 2014 at 08:58:19 UTC, Dicebot wrote:
 That reminds me about related topic - do we have any pragma / 
 attribute reserved for external tools? So that one could, for 
 example, disable analysis error for specific part of sourc code 
 without disabling it globally?

I assume you're talking about something like SuppressWarnings in Java? http://docs.oracle.com/javase/7/docs/api/java/lang/SuppressWarnings.html
Jan 21 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 21 January 2014 at 09:11:37 UTC, Brian Schott wrote:
 On Tuesday, 21 January 2014 at 08:58:19 UTC, Dicebot wrote:
 That reminds me about related topic - do we have any pragma / 
 attribute reserved for external tools? So that one could, for 
 example, disable analysis error for specific part of sourc 
 code without disabling it globally?

I assume you're talking about something like SuppressWarnings in Java? http://docs.oracle.com/javase/7/docs/api/java/lang/SuppressWarnings.html

I was thinking of a more fine-tuned thing, similar to gcc `__attribute__ (unused)` but generalised a bit to not interfere with normal attributes by using reserved namespace. Single SuppressWarnings (analysis reports in our case) can be a simpler compromise though.
Jan 21 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 21 January 2014 at 09:22:16 UTC, Walter Bright wrote:
 Coverity (a static analyzer) does checks based on whitespace 
 indentation. It's not a great leap from there to just format it.

One can also say that it is not a huge leap for compiler to do the same. Of course all those tool can share a lot of implementation and often are used together, but I think there is a value in keeping unrelated functionality separately available. UNIX-way ftw.
Jan 21 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/20/2014 8:34 PM, Brian Schott wrote:
 I've checked in code to the DScanner project that gives it some basic static
 analysis capabilities. When run with the --styleCheck option, it will warn
about
 a few things like empty declarations, implicit string concatenation, classes
 with lowercase_names, catching "Exception", and a few other things.

 There's a small feature wishlist in the project's README, but I'd like to get
 some opinions from the newsgroup: What kinds of errors have you seen in your
 code that you think a static analysis tool could help with?

Sooner or later, you're going to want to add data flow analysis. DFA will open up a universe of useful checks it can do. For example, you can do things like: class C { int x; } C foo() { return null; } int bar(int i) { auto c = i ? foo() : new C(); return c.x; // error, path to null dereference } and a heckuva lot more. For a laundry list, google Coverity and look at the bug reports it generates. Many of the reports have no meaning for D, as D has defined them out of existence, but there are plenty of others.
Jan 21 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Tuesday, 21 January 2014 at 09:30:45 UTC, Walter Bright wrote:
 On 1/21/2014 12:58 AM, Dicebot wrote:
 That reminds me about related topic - do we have any pragma / 
 attribute reserved
 for external tools? So that one could, for example, disable 
 analysis error for
 specific part of sourc code without disabling it globally?

Since we have user defined attributes, I don't see how anything further needs to be added to the language.

See "reserved namespace" reference. It does not need any special support from the language itself but some support from spec that will ensure that those attributes won't conflict with user code and other tools will be helpful. Probably even in form of guideline, not a rule.
Jan 21 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-01-21 05:34, Brian Schott wrote:
 I've checked in code to the DScanner project that gives it some basic
 static analysis capabilities. When run with the --styleCheck option, it
 will warn about a few things like empty declarations, implicit string
 concatenation, classes with lowercase_names, catching "Exception", and a
 few other things.

 There's a small feature wishlist in the project's README, but I'd like
 to get some opinions from the newsgroup: What kinds of errors have you
 seen in your code that you think a static analysis tool could help with?

Have a look at the Clang static analyzer as well. How accurate source information is kept? Xcode can, with the help of Clang, graphically show the flow path. -- /Jacob Carlborg
Jan 21 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 Coverity (a static analyzer) does checks based on whitespace 
 indentation.

This is good to have. Perhaps splitting the compiler in some parts could help people create such tools. Bye, bearophile
Jan 21 2014
prev sibling next sibling parent "Brian Schott" <briancschott gmail.com> writes:
On Tuesday, 21 January 2014 at 20:26:57 UTC, Walter Bright wrote:
 On 1/21/2014 1:33 AM, Dicebot wrote:
 See "reserved namespace" reference. It does not need any 
 special support from
 the language itself but some support from spec that will 
 ensure that those
 attributes won't conflict with user code and other tools will 
 be helpful.
 Probably even in form of guideline, not a rule.

This is quite overengineering to put such in the spec. coverity_warnings should do fine (i.e. prefix with your tool name). It's not any harder than coming up with names for your third party library.

"test.d(10): Error: undefined identifier coverity_warnings" In order for this to work the analysis tool would have to distribute a .d or .di file that is imported by any module that needs to suppress warnings. Java has the SuppressWarnings annotation in the standard java.lang to avoid this.
Jan 21 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/20/2014 8:34 PM, Brian Schott wrote:
 There's a small feature wishlist in the project's README, but I'd like to get
 some opinions from the newsgroup: What kinds of errors have you seen in your
 code that you think a static analysis tool could help with?

Here's a great source of potential rules to add: http://www.stroustrup.com/JSF-AV-rules.pdf
Jan 23 2014