www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DLP identify leaf functions

reply Jacob Carlborg <doob me.com> writes:
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
Nov 30 2018
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
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.
Nov 30 2018
prev sibling next sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
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.
Dec 01 2018
parent Jacob Carlborg <doob me.com> writes:
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
Dec 01 2018
prev sibling next sibling parent reply Anonymouse <asdf asdf.net> writes:
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}?
Dec 01 2018
parent Jacob Carlborg <doob me.com> writes:
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
Dec 02 2018
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
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.
Dec 02 2018
parent reply Jacob Carlborg <doob me.com> writes:
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
Dec 04 2018
parent welkam <wwwelkam gmail.com> writes:
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
Dec 11 2018