On Tuesday, 15 November 2016 at 16:50:47 UTC, Basile B. wrote:
>
> pffff you dont get the point.
> The point is when an IDE message leads you to this:
> http://imgur.com/a/6zLHU

I really don't get it.
What is actionable about that metric ?

On Tuesday, 15 November 2016 at 16:53:42 UTC, Stefan Koch wrote:
> On Tuesday, 15 November 2016 at 16:50:47 UTC, Basile B. wrote:
>>
>> pffff you dont get the point.
>> The point is when an IDE message leads you to this:
>> http://imgur.com/a/6zLHU
>
> I really don't get it.
> What is actionable about that metric ?

The Halstead complexity is able to detect the functions that need more unit test and more reviews.

On 11/15/2016 06:46 PM, Stefan Koch wrote:
> 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.

When doing so, try to forget that static analysis is the intended goal. It has to be naturally usable for any other purpose too, focusing on one specific application case is likely only harm design decisions.

On Tuesday, 15 November 2016 at 16:59:49 UTC, Dicebot wrote:
> On 11/15/2016 06:46 PM, Stefan Koch wrote:
>> 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.
>
> When doing so, try to forget that static analysis is the intended goal. It has to be naturally usable for any other purpose too, focusing on one specific application case is likely only harm design decisions.

It's a compiler frontend.
I cannot see any other purposes then code-analysis and code-transformation.
Regarding Transformations I wanted to write a good D transformation tool for years now.

On Tuesday, 15 November 2016 at 16:57:44 UTC, Basile B. wrote:
> On Tuesday, 15 November 2016 at 16:53:42 UTC, Stefan Koch wrote:
>> On Tuesday, 15 November 2016 at 16:50:47 UTC, Basile B. wrote:
>>>
>>> pffff you dont get the point.
>>> The point is when an IDE message leads you to this:
>>> http://imgur.com/a/6zLHU
>>
>> I really don't get it.
>> What is actionable about that metric ?
>
> The Halstead complexity is able to detect the functions that need more unit test and more reviews.

Like shown here:

https://www.youtube.com/watch?v=_asYu0f38ks&nohtml5=False#t=6.543481

;)

On 11/15/2016 07:05 PM, Stefan Koch wrote:
>> When doing so, try to forget that static analysis is the intended goal. It has to be naturally usable for any other purpose too, focusing on one specific application case is likely only harm design decisions.
> 
> It's a compiler frontend.

Very good observation :P

> I cannot see any other purposes then code-analysis and code-transformation. Regarding Transformations I wanted to write a good D transformation tool for years now.

With that approach you can also say that code analysis is subset of code of code transformation (it transforms code to list of warnings!) and thus that is the only purpose. I doubt it is very useful definition :)

Language frontend as a library must allow any sort of reasoning about source code that compiler can normally do. What library user will do with that reasoning is not of ones concern - it can be analysis or transpilation to another language or even dumb AST pretty-printing. No matter, in the core one has to be able to do `import dlang.frontend` and write own visiting code.

On Wednesday, 16 November 2016 at 10:45:54 UTC, Dicebot wrote:
> On 11/15/2016 07:05 PM, Stefan Koch wrote:
>>> [...]
>> 
>> It's a compiler frontend.
>
> Very good observation :P
>
>> I cannot see any other purposes then code-analysis and code-transformation. Regarding Transformations I wanted to write a good D transformation tool for years now.
>
> With that approach you can also say that code analysis is subset of code of code transformation (it transforms code to list of warnings!) and thus that is the only purpose. I doubt it is very useful definition :)
>
> Language frontend as a library must allow any sort of reasoning about source code that compiler can normally do. What library user will do with that reasoning is not of ones concern - it can be analysis or transpilation to another language or even dumb AST pretty-printing. No matter, in the core one has to be able to do `import dlang.frontend` and write own visiting code.

Point taken.
My plan does not include to change the modular structure of the frontend.
It's more focused on improving perforance and ease-of-use of the AST and AST-Visitors.

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.

By the way there are several problems with static analysis of D code. Mostly related to template metaprogramming and conditional compilation.

- UFCS: at least in libdparse, not visited with a FunctionCall
- static if
- version
- mixin() and mixin

Does your DDMD-based AST handle these cases ?

On Wednesday, 16 November 2016 at 14:06:16 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.
>
> By the way there are several problems with static analysis of D code. Mostly related to template metaprogramming and conditional compilation.
>
> - UFCS: at least in libdparse, not visited with a FunctionCall
> - static if
> - version
> - mixin() and mixin
>
> Does your DDMD-based AST handle these cases ?

Certainly!
However only on mixin that are actually used.
Only the conditions that are taken are visited.