I would like to announce a new project I've started, called DLP (D Language Processing). Currently it's quite experimental but the idea is that it would contain a collection of commands for inspecting D code in various ways. It uses the DMD frontend as a library (the Dub package) to process D code.

This first release only contains one command, "leaf-functions". It will print out all leaf functions to standard out. A "leaf function" is considered a function that doesn't call any other functions or doesn't have a body. The use case for this is if you have a code base that you would like to add attributes to. Since most attributes causes the function they're attached to be constraint in which other functions they can call, "@nogc" functions can only call other "@nogc" functions, "pure" functions can only call other "pure" functions and so on. Therefore it makes most sense when starting to add attributes to a code base to start with the leaf functions, the functions that don't call any other functions.

Pre-compiled binaries are available for macOS, Linux and Windows.

https://github.com/jacob-carlborg/dlp

-- 
/Jacob Carlborg

On Friday, 30 November 2018 at 20:10:05 UTC, Jacob Carlborg wrote:
> I would like to announce a new project I've started, called DLP (D Language Processing). Currently it's quite experimental but the idea is that it would contain a collection of commands for inspecting D code in various ways. It uses the DMD frontend as a library (the Dub package) to process D code.
>
> This first release only contains one command, "leaf-functions". It will print out all leaf functions to standard out. A "leaf function" is considered a function that doesn't call any other functions or doesn't have a body. The use case for this is if you have a code base that you would like to add attributes to. Since most attributes causes the function they're attached to be constraint in which other functions they can call, "@nogc" functions can only call other "@nogc" functions, "pure" functions can only call other "pure" functions and so on. Therefore it makes most sense when starting to add attributes to a code base to start with the leaf functions, the functions that don't call any other functions.
>
> Pre-compiled binaries are available for macOS, Linux and Windows.
>
> https://github.com/jacob-carlborg/dlp
In all honestly I think the compiler should make some test with regards to the system attrubutes and create attributes if it passes or fails. @unpure, @unsafe, @gc.
The downside of this is the increase of compile time.

On Friday, 30 November 2018 at 20:10:05 UTC, Jacob Carlborg wrote:
> I would like to announce a new project I've started, called DLP (D Language Processing). Currently it's quite experimental but the idea is that it would contain a collection of commands for inspecting D code in various ways. It uses the DMD frontend as a library (the Dub package) to process D code.
>
> https://github.com/jacob-carlborg/dlp

Really nice! I have some ideas about data-flow analysis and this allows some easy experimenting without forking the compiler.

On 2018-12-01 11:13, Sebastiaan Koppe wrote:

> Really nice! I have some ideas about data-flow analysis and this allows some easy experimenting without forking the compiler.

Thanks. I've been thinking the same about experimenting with the compiler.

-- 
/Jacob Carlborg

On Friday, 30 November 2018 at 20:10:05 UTC, Jacob Carlborg wrote:
> I would like to announce a new project I've started, called DLP (D Language Processing). Currently it's quite experimental but the idea is that it would contain a collection of commands for inspecting D code in various ways. It uses the DMD frontend as a library (the Dub package) to process D code.

Looks interesting.

My project requires a bunch of version identifiers to actually compile. Is there a way to pass these, or ideally a way to make it parse them from dub.{json,sdl}?

On 2018-12-01 13:31, Anonymouse wrote:

> Looks interesting.
> 
> My project requires a bunch of version identifiers to actually compile. Is there a way to pass these, or ideally a way to make it parse them from dub.{json,sdl}?

No, there's currently no way. The next step would be to allow to pass all the same flags as the DMD compiler allows.

-- 
/Jacob Carlborg

On Friday, 30 November 2018 at 20:10:05 UTC, Jacob Carlborg wrote:
> I would like to announce a new project I've started, called DLP (D Language Processing). Currently it's quite experimental but the idea is that it would contain a collection of commands for inspecting D code in various ways. It uses the DMD frontend as a library (the Dub package) to process D code.

What a timing. I am working on (slowly) on a tool that would get all struct and class declarations and for each of them get functions in which they are used. Then combine them with profiling data to find data structures that are hot and how changing them affects performance. The only code that is written is partially parsing perf.data file and the rest is missing. It would be wonderful if your tool could emit such functions then my job would be easy. Parsing would have been done if perf.data format was fully documented.

On 2018-12-02 17:57, welkam wrote:

> What a timing. I am working on (slowly) on a tool that would get all struct and class declarations and for each of them get functions in which they are used. Then combine them with profiling data to find data structures that are hot and how changing them affects performance. The only code that is written is partially parsing perf.data file and the rest is missing. It would be wonderful if your tool could emit such functions then my job would be easy. Parsing would have been done if perf.data format was fully documented.

Something like "find all references"?

-- 
/Jacob Carlborg

On Tuesday, 4 December 2018 at 11:02:11 UTC, Jacob Carlborg wrote:
> On 2018-12-02 17:57, welkam wrote:
>
>> What a timing. I am working on (slowly) on a tool that would get all struct and class declarations and for each of them get functions in which they are used. Then combine them with profiling data to find data structures that are hot and how changing them affects performance. The only code that is written is partially parsing perf.data file and the rest is missing. It would be wonderful if your tool could emit such functions then my job would be easy. Parsing would have been done if perf.data format was fully documented.
>
> Something like "find all references"?

Late response is better than none i guess. References are bad word because it could mean references as passed to functions or pointers. What I am looking is occurrences in functions. Whether class/struct is created or passed trough pointer I want to know about it. If class/struct is put into container I want to track that as well. I want to know all uses of that data type.

One frequent thing people say on reddit is that phobos is based on GC. It would be nice if there was a tool that could report what percentage of functions actually use GC and what are marked as @nogc