This comes up a lot.
As far as I know, it's not solved. What shall we do?

I feel like a simple solution would be to have the compiler emit a <filename>_mixin.d file populated with all the mixin expansions beside the .obj files, and have the debuginfo refer to that fabricated source file?

It might look a little bit weird jumping into code where the surrounding scope is not visible (unless that were copied over too?), but it's better than what we have now.

Are there any other commonly proposed solutions?

On Sunday, 2 October 2016 at 03:36:31 UTC, Manu wrote:
> This comes up a lot.
> As far as I know, it's not solved. What shall we do?
>
> I feel like a simple solution would be to have the compiler emit a <filename>_mixin.d file populated with all the mixin expansions beside the .obj files, and have the debuginfo refer to that fabricated source file?
>
> It might look a little bit weird jumping into code where the surrounding scope is not visible (unless that were copied over too?), but it's better than what we have now.
>
> Are there any other commonly proposed solutions?

We should create a file where the string-mixins are expanded, I agree.
However I am not sure if this is a quick-fix or a more tricky thing.

In theory the PrettyPrinter we have should give as a way to produce such a file.

I have been meaning to work on this issue for a while now, alas there is always something else to do :)

On 10/02/2016 01:00 AM, Stefan Koch wrote:
> We should create a file where the string-mixins are expanded, I agree.
> However I am not sure if this is a quick-fix or a more tricky thing.

Yes, Stefan it would be terrific if you could keep an eye on it while working on the engine. A file with properly handed dependencies could serve as instantiation cache and save a ton of re-instantiation waste. Thanks! -- Andrei

On Sunday, 2 October 2016 at 05:00:07 UTC, Stefan Koch wrote:
> We should create a file where the string-mixins are expanded, I agree.

Further to this. I tried generating .di files the other day for code based on Binderoo. None of the mixins were expanded, which resulted in the compiler needing to do all that work again anyway and negating the effect of a precompiled library.

If you get to doing that work, it would be fab if you could apply it to .di generation. If not as the default, then at least as a switch I can provide on the command line.

On 3 October 2016 at 00:08, Ethan Watson via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 2 October 2016 at 05:00:07 UTC, Stefan Koch wrote:
>>
>> We should create a file where the string-mixins are expanded, I agree.
>
>
> Further to this. I tried generating .di files the other day for code based on Binderoo. None of the mixins were expanded, which resulted in the compiler needing to do all that work again anyway and negating the effect of a precompiled library.
>
> If you get to doing that work, it would be fab if you could apply it to .di generation. If not as the default, then at least as a switch I can provide on the command line.

That's genius! :)

On 10/02/2016 10:44 PM, Manu via Digitalmars-d wrote:
> On 3 October 2016 at 00:08, Ethan Watson via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Sunday, 2 October 2016 at 05:00:07 UTC, Stefan Koch wrote:
>>>
>>> We should create a file where the string-mixins are expanded, I agree.
>>
>>
>> Further to this. I tried generating .di files the other day for code based
>> on Binderoo. None of the mixins were expanded, which resulted in the
>> compiler needing to do all that work again anyway and negating the effect of
>> a precompiled library.
>>
>> If you get to doing that work, it would be fab if you could apply it to .di
>> generation. If not as the default, then at least as a switch I can provide
>> on the command line.
>
> That's genius! :)

Yah, very very interesting idea. -- Andrei

On Sunday, 2 October 2016 at 12:27:23 UTC, Andrei Alexandrescu wrote:
>
> Yes, Stefan it would be terrific if you could keep an eye on it while working on the engine. A file with properly handed dependencies could serve as instantiation cache and save a ton of re-instantiation waste. Thanks! -- Andrei

instantiation ?
Do you mean mixin-expansion ?
or are you talking about mixins created in templates ?

Although Caching mixin expansions hits on the same problem as chaching template-instances, it is more difficult since a mixin can appear anywhere.
and one has to worry about a much wider scope.

I'll see what I can come up with, for now the debugging is priority.
@Ethan can you share code illustrating your usecase.
(My head is inside compiler internals and building test-code is a rather unpleasant context switch)

On Monday, 3 October 2016 at 11:42:25 UTC, Stefan Koch wrote:
> @Ethan can you share code illustrating your usecase.
> (My head is inside compiler internals and building test-code is a rather unpleasant context switch)

You should be able to do everything with the example code you have. My intention there is to compile everything in the acorelibrary module in to a library and statically link against that. As such, you'll want to do the .di generation on those files. The behaviour right now is that all the Binderoo mixins will not expand.

On 10/03/2016 07:42 AM, Stefan Koch wrote:
> On Sunday, 2 October 2016 at 12:27:23 UTC, Andrei Alexandrescu wrote:
>>
>> Yes, Stefan it would be terrific if you could keep an eye on it while
>> working on the engine. A file with properly handed dependencies could
>> serve as instantiation cache and save a ton of re-instantiation waste.
>> Thanks! -- Andrei
>
> instantiation ?
> Do you mean mixin-expansion ?
> or are you talking about mixins created in templates ?

Mixin expansions.

> Although Caching mixin expansions hits on the same problem as chaching
> template-instances, it is more difficult since a mixin can appear anywhere.
> and one has to worry about a much wider scope.
>
> I'll see what I can come up with, for now the debugging is priority.
> @Ethan can you share code illustrating your usecase.
> (My head is inside compiler internals and building test-code is a rather
> unpleasant context switch)

Understood, then keep this on the back burner and forge ahead with the warm cache. Thanks! -- Andrei

On Sunday, 2 October 2016 at 03:36:31 UTC, Manu wrote:
> This comes up a lot.
> As far as I know, it's not solved. What shall we do?
>
> I feel like a simple solution would be to have the compiler emit a <filename>_mixin.d file populated with all the mixin expansions beside the .obj files, and have the debuginfo refer to that fabricated source file?
>
> It might look a little bit weird jumping into code where the surrounding scope is not visible (unless that were copied over too?), but it's better than what we have now.
>
> Are there any other commonly proposed solutions?

Yes, having the mixins expanded without the surrounding code would make it difficult to debug in some cases.  Maybe generating the entire source with the expanded mixins is another option?

mycode.d
obj/mycode_processed.d

Maybe this idea could also be expanded to template instantiation?