Need clarification on dmd symbol generation

Dicebot m.strashun at gmail.com
Wed Apr 10 05:36:12 PDT 2013


On Wednesday, 10 April 2013 at 11:53:51 UTC, Robert wrote:
> TemplateInstance::enclosing, also does not get you the 
> instantiating context, referring to the comment in the source 
> code, I think for my tests it was null.
>
> importedFrom was no solution either. The only thing that worked 
> for me was walking up with tinst and then use loc. This way you 
> get the instantiating file. (Got that from 
> printInstantiationTrace) I think it should be possible to use 
> this found file name to find the module by iterating 
> Module::modules, but I have not even bothered trying, because I 
> felt there has to be some better way, unfortunately I also got 
> no replies.
>
> At least it helps that I am not alone with this problem :-)
>
> Maybe it is not entirely unlikely that there is in fact no 
> better way, as apart from "where do I put the instantiated 
> template" and error messages there is really no need to know 
> where the template got instantiated.

Excited to see I am not the only one caring about this! :) 
Module* can be found via tinst->scope->module, so it is pretty 
straightforward. I have tried to use this and it _almost_ worked 
but some symbols were still missing (I have mentioned example 
with map and range before, can reduce test case if you are 
interested).

importFrom is obvious hack instead of precisely tracking symbol 
source - "lets just emit weak symbols for every compiled file 
from all his imports and let linker clean up the mess".

Considering Kenji's explanation this seems to work as I have 
initially understood. Then I need to reduce that case and see why 
those std.range template symbols are not propagated to the top of 
the chain.

This is a major blocker for getting reliable and efficient 
separate compilation and bugzilla issue references in topic is 
just an observable side-effect.


More information about the Digitalmars-d mailing list