2013/4/10 Dicebot <m.strashun@gmail.com>

> On Wednesday, 10 April 2013 at 09:37:44 UTC, kenji hara wrote:
>
>> OK. I don't understand the issue enough, but I'd like to help you.
>>
>> - TemplateInstance::tinst may represent the enclosing template instance that 'this' instance is instantiated. It is set in TemplateInstance::semantic(|2|**3) for its member's semantic process.
>>
>> - TemplateInstance::enclosing may represent the parent of nested template instance. If a template is instantiated in function scope with implicit context, it points the function. It is set in TemplateInstance::**hasNestedArgs.
>>
>> - Module::importedFrom may represents the "root module" of import chain.
>> it
>> points one of the module that listed in command line.
>>
>> Good luck.
>>
>> Kenji Hara
>>
>
> I see no TemplateInstance::enclosing, only Scope::enclosing and TemplateInstance is not Scope descendant.


Very recently TemplateInstance::isnested is renamed to TemplateInstance::enclosing.


> Essentially I need to emit symbols not for "importedFrom" module but for module of top-most tinst in chain. I supposed that iterating tinst can do the trick, but it is not. For example, when map is used, it call templated range functions somewhere down the line and iterating up from those don't get you initial map call scope. (Same issue in printInstantiationTrace as it uses this method).
>

It sounds that using TemplateInstance::enclosing is correct.

Kenji Hara

On Wednesday, 10 April 2013 at 12:36:35 UTC, kenji hara wrote:
> ...

Can't really express how big my gratitude is! :) Already trying "enclosing".

You now what? It worked.

Before:
$ nm a.o | wc -l
358

After:
$ nm a.o | wc -l
68

I'll run a full test suite and do the pull request.

Kenji you are my hero ;)

> 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).

For me tinst->scope->module resolved to the module where the template is declared not the instantiating one, while tinst->loc.filename is the instantiating file. I am interested!



> 
> 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.

Getting reliable building is also quite important for dub, I don't want to work around dmd bugs (sometimes not even feasible), I would rather fix them :-)

On Wednesday, 10 April 2013 at 14:15:11 UTC, Robert wrote:
> ...

Yes, have found some issues with scope->module and finally resorted to getModule().
Please follow pull request : https://github.com/D-Programming-Language/dmd/pull/1882

On Wed, 2013-04-10 at 15:50 +0200, Dicebot wrote:
> You now what? It worked.
> 
> Before:
> $ nm a.o | wc -l
> 358
> 
> After:
> $ nm a.o | wc -l
> 68
> 
> I'll run a full test suite and do the pull request.
> 
> Kenji you are my hero ;)

:-( Still wrong output for my code. I commented on your pull request with more details.

On Wednesday, 10 April 2013 at 15:16:31 UTC, Robert wrote:
> On Wed, 2013-04-10 at 15:50 +0200, Dicebot wrote:
>> You now what? It worked.
>> 
>> Before:
>> $ nm a.o | wc -l
>> 358
>> 
>> After:
>> $ nm a.o | wc -l
>> 68
>> 
>> I'll run a full test suite and do the pull request.
>> 
>> Kenji you are my hero ;)
>
> :-( Still wrong output for my code. I commented on your pull request
> with more details.

Please add sample code to http://d.puremagic.com/issues/show_bug.cgi?id=9571

On Wednesday, 10 April 2013 at 16:01:08 UTC, deadalnix wrote:
> Please add sample code to http://d.puremagic.com/issues/show_bug.cgi?id=9571

I know what Robert is speaking about, it is different issue though also related to template symbols. It does not belong to 9571 but I try to address it too.