• Frustrated (56/56) Mar 25 2014 Is it possible for the compiler to warn/mark functions,
• Meta (2/58) Mar 25 2014 https://github.com/D-Programming-Language/dmd/pull/1886

"Frustrated" <Frustrated nowhere.com> writes:

Is it possible for the compiler to warn/mark functions, 
templates, and types that use the GC?

e.g.,  I have a mixin template that has a static associative 
array. At some point I would like to remove the GC dependence but 
the only way to ensure I'll remember is to add some type of 
warning/pragma msg.

It would be nice, in fact, to be able to mark things as  nogc or 
whatever when they are no longer dependent on the GC. To do this 
would require scanning all code which is very time consuming. If 
the compiler could report(make a table, say) of all things that 
it believe are gc dependent(and not GC dependent) then it would 
be easier to handle.

e.g.,

function name      GC     nogc
foo               yes
bar               no
baz               no       x
fubar              ?
fubaz              ?
     fubar          ?       x
func1              ?       x
func2              no
     func1          ?       x

fubaz uses fubar and fubar is unknown hence fubaz is 
unknown(dependencies shown by indentation). One could force a 
function to be GC independent but unverified by having the nogc 
attribute(e.g., if it uses functions that can't be verified by 
the compiler). e.g., func1 is assumed not to be gc dependent, 
func2 uses func1 and verified not to be gc dependent by assuming 
func1 isn't.

Having such a list could result in having GC dependent functions 
marked with nogc. This should result in an error.

It should be rather easy to deal with and easy for the compiler 
to generate such a table. The compiler either implicitly 
generates calls to the GC(hence marked yes under the GC column), 
the user explicitly calls the GC(again, marked), the user uses 
types that are GC dependent(GC type allocations), or calls 
functions that use the GC.

By having a table we can easily determine how much a function is 
dependent on the GC and how to go about making it not. (if it 
just dependents on functions that are using the GC then it would 
not use the GC but have a list of functions that do or are not 
verified.

I suppose it could get a bit complex with all the 
possibilities(operator overloading, etc but the compiler doesn't 
have to check everything(or anything) as it has the ability to 
mark things as unverified(?).

What this does is not necessarily remove GC dependence but 
defines a way to do so. I could, for example, use it to remove 
all dependence of the GC in my own code but still use the phobos 
which is GC dependent. If phobos ever become GC independent I 
could generate the table and see that all my functions are 
verified to be GC independent and possibly have a utility 
function to mark them with  nogc(scan the table and mark by 
adding the  nogc to the source code... table could include file 
and line number).

"Meta" <jared771 gmail.com> writes:

On Tuesday, 25 March 2014 at 17:37:34 UTC, Frustrated wrote:
 Is it possible for the compiler to warn/mark functions, 
 templates, and types that use the GC?

 e.g.,  I have a mixin template that has a static associative 
 array. At some point I would like to remove the GC dependence 
 but the only way to ensure I'll remember is to add some type of 
 warning/pragma msg.

 It would be nice, in fact, to be able to mark things as  nogc 
 or whatever when they are no longer dependent on the GC. To do 
 this would require scanning all code which is very time 
 consuming. If the compiler could report(make a table, say) of 
 all things that it believe are gc dependent(and not GC 
 dependent) then it would be easier to handle.

 e.g.,

 function name      GC     nogc
 foo               yes
 bar               no
 baz               no       x
 fubar              ?
 fubaz              ?
     fubar          ?       x
 func1              ?       x
 func2              no
     func1          ?       x

 fubaz uses fubar and fubar is unknown hence fubaz is 
 unknown(dependencies shown by indentation). One could force a 
 function to be GC independent but unverified by having the nogc 
 attribute(e.g., if it uses functions that can't be verified by 
 the compiler). e.g., func1 is assumed not to be gc dependent, 
 func2 uses func1 and verified not to be gc dependent by 
 assuming func1 isn't.

 Having such a list could result in having GC dependent 
 functions marked with nogc. This should result in an error.

 It should be rather easy to deal with and easy for the compiler 
 to generate such a table. The compiler either implicitly 
 generates calls to the GC(hence marked yes under the GC 
 column), the user explicitly calls the GC(again, marked), the 
 user uses types that are GC dependent(GC type allocations), or 
 calls functions that use the GC.

 By having a table we can easily determine how much a function 
 is dependent on the GC and how to go about making it not. (if 
 it just dependents on functions that are using the GC then it 
 would not use the GC but have a list of functions that do or 
 are not verified.

 I suppose it could get a bit complex with all the 
 possibilities(operator overloading, etc but the compiler 
 doesn't have to check everything(or anything) as it has the 
 ability to mark things as unverified(?).

 What this does is not necessarily remove GC dependence but 
 defines a way to do so. I could, for example, use it to remove 
 all dependence of the GC in my own code but still use the 
 phobos which is GC dependent. If phobos ever become GC 
 independent I could generate the table and see that all my 
 functions are verified to be GC independent and possibly have a 
 utility function to mark them with  nogc(scan the table and 
 mark by adding the  nogc to the source code... table could 
 include file and line number).

https://github.com/D-Programming-Language/dmd/pull/1886