Re: DMD Symbol Reference Analysis Pass

2015-05-21 Thread via Digitalmars-d-learn

On Wednesday, 20 May 2015 at 09:41:09 UTC, Per Nordlöw wrote:

On Wednesday, 20 May 2015 at 09:27:06 UTC, Per Nordlöw wrote:


Ping!?


Re: DMD Symbol Reference Analysis Pass

2015-05-21 Thread John Colvin via Digitalmars-d-learn

On Thursday, 21 May 2015 at 11:52:34 UTC, Per Nordlöw wrote:

On Wednesday, 20 May 2015 at 09:41:09 UTC, Per Nordlöw wrote:

On Wednesday, 20 May 2015 at 09:27:06 UTC, Per Nordlöw wrote:


Ping!?


I think you'd be more likely to get responses to this sort of 
question in the main group, not D.learn, it's a bit beyond 
Learning D.


Re: DMD Symbol Reference Analysis Pass

2015-05-20 Thread via Digitalmars-d-learn

On Wednesday, 20 May 2015 at 08:52:23 UTC, Per Nordlöw wrote:
Does DMD currently do any analysis of references to a symbol in 
a given scope? If not where could this information be extracted 
(in which visitor/callback) and in what structure should it, if 
so, be stored?


I'm guessing

Scope::insert(Dsymbol*s)
{
if (VarDeclaration *vd = s-isVarDeclaration())
{
// ..


is of interest. Is there another member function called everytime 
a Dsymbol is referenced?


I'm guessing MODFlags plays a role here aswell.


DMD Symbol Reference Analysis Pass

2015-05-20 Thread via Digitalmars-d-learn
Does DMD currently do any analysis of references to a symbol in a 
given scope? If not where could this information be extracted (in 
which visitor/callback) and in what structure should it, if so, 
be stored?


Reason: After having read about Rust's data-flow (and in turn 
escape) analysis I'm very curious about how difficult it would be 
to add more clever type inference, of for example symbol 
mutability, based on this analysis.


I'm asking again because of the work recently done in DIP-25, 
that may be related to this problem.


Re: DMD Symbol Reference Analysis Pass

2015-05-20 Thread via Digitalmars-d-learn

On Wednesday, 20 May 2015 at 09:27:06 UTC, Per Nordlöw wrote:

Two cases come to my mind:

A: Non-Templated Function: must be @safe (or perhaps @trusted) 
pure and parameter must qualified as const (or in).
B: Templated Function: Usage of parameter in body must be 
non-mutating; meaning no lhs of assignment op (=, +=, ...), and 
calls to functions that take parameter as argument must be 
transitively fulfill A and B.