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