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.

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.

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.

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

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

"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! 

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

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.

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.

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.