DMD Symbol Reference Analysis Pass

via Digitalmars-d digitalmars-d at puremagic.com
Tue May 26 03:19:51 PDT 2015


On Monday, 25 May 2015 at 12:43:04 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?
>
> 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 instance, mutability, 
> based on this analysis.
>
> 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.
>
> 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.
>
> I'm asking again because of the work recently done in DIP-25,
> that may be related to this problem.

Sorry, can't answer this, as I don't know enough about DMD's 
inner workings. But I noted down some ideas on this topic 
relating to my scope proposal.

Algorithm for scope inference:
http://wiki.dlang.org/User_talk:Schuetzm/scope2#Implementation

... to be used in templates and for enforcing these rules:
http://wiki.dlang.org/User:Schuetzm/scope3#.40safe-ty_violations_with_borrowing

Personally I don't think local inference of mutability (const) is 
of much help. However, a kind of "borrow checker" is necessary to 
avoid the safety problems that arise from borrowing (see the 
thread "RCArray is unsafe" [1]). This happens to involve very 
similar analysis to what you're thinking of. In contrast to Rust, 
it is relatively simple, because we don't support transfer of 
ownership (moving) as Rust does.

[1] 
http://forum.dlang.org/thread/huspgmeupgobjubtsmfe@forum.dlang.org


More information about the Digitalmars-d mailing list