Hi Guys,

I was wondering how much interest in static analysis exists in this community .
DMD already has rudimentary support for these kinds of things.

On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I was wondering how much interest in static analysis exists in this community .
> DMD already has rudimentary support for these kinds of things.

Whoops I accidentally pressed enter too soon.

I am currently working on extending the existing support a little because the new CTFE engine really profits form having more information up-front.

At the moment it is rather cumbersome to write analysis passes.
And passing information from pass to pass is not exactly trivial either.

Therefore I am planning to spent some time next year to implement and polish a facility that allows matching patterns on dmd's AST in an event driven style.

However this will only bear fruit if there is actual interest in static analysis for D.

One possible application would be to automatically produce a precise complexity analysis for algorithms based on the compilers knowledge of the range interface.

Another one is to automatically reduce template-bloat and other duplicated code-blocks early on. (This one is my intended target.)

Cheers,
Stefan

if it will be independent utility -- yes. dmdfe part -- no.

On Tuesday, 15 November 2016 at 15:28:14 UTC, ketmar wrote:
> if it will be independent utility -- yes. dmdfe part -- no.

It would relay on the parser of the dmdfe, and parts of dmd's semantic analysis.

DMD will be much nicer to work with the facility envision.
As I see it there is little reason for writing yet another D parser.

On Tuesday, 15 November 2016 at 15:33:30 UTC, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 15:28:14 UTC, ketmar wrote:
>> if it will be independent utility -- yes. dmdfe part -- no.
>
> It would relay on the parser of the dmdfe, and parts of dmd's semantic analysis.
>
> DMD will be much nicer to work with the facility envision.
> As I see it there is little reason for writing yet another D parser.

the more features dmdfe will get, the slower (and more memory-hungry) it will become. so i don't want any fancy (and even useful ;-) features in dmd itself (that's what i meant when i wrote "dmdfe"). if it will be separate app based on dmdfe -- sure, it would be great!

On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:
> Hi Guys,
>
> I was wondering how much interest in static analysis exists in this community .
> DMD already has rudimentary support for these kinds of things.

cyclic complexity
NPath complexity
Halstead complexity

3 nice fields of static analysis.

I'm currently working on Halstead (https://github.com/BBasile/Coedit/blob/master/dastworx/src/halstead.d)

The Halstead metric (1977) is often considered as ratio of the number of line code, while it's actually not at all. The Halstead is based on the operations and the operations arguments. You can have small functions using a lot of operands that will be bug prone. You can have huge functions with very few operands used and that are not bug prone. The Halstead metric can detect them. It can tell you: "take care of this function".

;]

On Tuesday, 15 November 2016 at 16:28:30 UTC, Basile B. wrote:
> On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I was wondering how much interest in static analysis exists in this community .
>> DMD already has rudimentary support for these kinds of things.
>
> cyclic complexity
> NPath complexity
> Halstead complexity
>
> 3 nice fields of static analysis.
>
> I'm currently working on Halstead (https://github.com/BBasile/Coedit/blob/master/dastworx/src/halstead.d)
>
> The Halstead metric (1977) is often considered as ratio of the number of line code, while it's actually not at all. The Halstead is based on the operations and the operations arguments. You can have small functions using a lot of operands that will be bug prone. You can have huge functions with very few operands used and that are not bug prone. The Halstead metric can detect them. It can tell you: "take care of this function".
>
> ;]

I think you mixed up Pow and Xor.

You will probably want to change from a AA to a normal array and just assign a numeric index to each expression you care about :)

On 11/15/2016 04:57 PM, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:
>> Hi Guys,
>>
>> I was wondering how much interest in static analysis exists in this
>> community .
>> DMD already has rudimentary support for these kinds of things.

I'd put it in a different perspective - we desperately need DMD FE (with all semantic phases) available as fully-stand alone independent library. For example, there is already DScanner (https://github.com/Hackerpilot/Dscanner) for static analysis but amount of things one can check with only lexer/parser is very limited in D.

Once we have such library, it opens up world of many useful tools - separating all warnings into dedicated static analysis tool, providing automatic project upgrade scripts which work reliably, visualize mixin expansions and so on.

But I'd sincerely advise against any ad-hoc solution that is built into DMD itself.

On Tuesday, 15 November 2016 at 16:39:22 UTC, Dicebot wrote:
> [ .... ]
> But I'd sincerely advise against any ad-hoc solution that is built into DMD itself.

It seems I did not clearly state this.
I mean to provide the general plumbing that is needed for the dmd-fe,
to utilize it for static analysis.
I do not intend to cram all sorts of checking functionality inside the compiler.

Though what I am planning will also make it easier to extend the optimizer inside dmd, and improve it's efficiency.

On Tuesday, 15 November 2016 at 16:38:39 UTC, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 16:28:30 UTC, Basile B. wrote:
>> On Tuesday, 15 November 2016 at 14:45:29 UTC, Stefan Koch wrote:
>>> Hi Guys,
>>>
>>> I was wondering how much interest in static analysis exists in this community .
>>> DMD already has rudimentary support for these kinds of things.
>>
>> cyclic complexity
>> NPath complexity
>> Halstead complexity
>>
>> 3 nice fields of static analysis.
>>
>> I'm currently working on Halstead (https://github.com/BBasile/Coedit/blob/master/dastworx/src/halstead.d)
>>
>> The Halstead metric (1977) is often considered as ratio of the number of line code, while it's actually not at all. The Halstead is based on the operations and the operations arguments. You can have small functions using a lot of operands that will be bug prone. You can have huge functions with very few operands used and that are not bug prone. The Halstead metric can detect them. It can tell you: "take care of this function".
>>
>> ;]
>
> I think you mixed up Pow and Xor.
>
> You will probably want to change from a AA to a normal array and just assign a numeric index to each expression you care about :)

pffff you dont get the point.
The point is when an IDE message leads you to this:
http://imgur.com/a/6zLHU