On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler wrote:

>
> 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
That was my intention.
> Maybe this idea could also be expanded to template instantiation?
 Oh yes. it is not that more much work :)

On 4 October 2016 at 04:21, Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler wrote:
>
>>
>> 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
>
> That was my intention.
>>
>> Maybe this idea could also be expanded to template instantiation?
>
>  Oh yes. it is not that more much work :)

What case of template instantiation where there are no mixins involved
would this make significantly simpler to debug? (I don't know this is
a critical debugability problem as it is...)
Do you mean just substituting 'T' with actual types? resolving static
if's? Hard to know what it should do...

Actually, one case that often bites me is static-foreach unrolling.
That's borderline impossible to debug.
foreach(m; __traits(allMembers,T)) is the classic impossible to debug case.

On Tuesday, 4 October 2016 at 01:20:01 UTC, Manu wrote:
> On 4 October 2016 at 04:21, Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler wrote:
>>
>>>
>>> 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
>>
>> That was my intention.
>>>
>>> Maybe this idea could also be expanded to template instantiation?
>>
>>  Oh yes. it is not that more much work :)
>
> What case of template instantiation where there are no mixins involved
> would this make significantly simpler to debug? (I don't know this is
> a critical debugability problem as it is...)
> Do you mean just substituting 'T' with actual types? resolving static
> if's? Hard to know what it should do...
>
> Actually, one case that often bites me is static-foreach unrolling.
> That's borderline impossible to debug.
> foreach(m; __traits(allMembers,T)) is the classic impossible to debug case.

static ifs are resolved when the compiler sees the template-instance in semantic3.
And that makes a huge difference in some cases where a template is generated by a string-mixin for example.

is not that big of a deal to print out unrolled static foreach.
(as in I can implement in the compiler within 2 days)

On Tuesday, 4 October 2016 at 01:59:11 UTC, Stefan Koch wrote:
> On Tuesday, 4 October 2016 at 01:20:01 UTC, Manu wrote:
>> On 4 October 2016 at 04:21, Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>> On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler wrote:
>>>
>>>>
>>>> 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
>>>
>>> That was my intention.
>>>>
>>>> Maybe this idea could also be expanded to template instantiation?
>>>
>>>  Oh yes. it is not that more much work :)

A small update on this.
The POC works rather well ...
Except for cases of massive template recursion. (binderoo and most of std.traits)
In such cases a stack overflow occurs inside the prettyPrinter.

I am trying to find a work-around.

On Wednesday, 5 October 2016 at 02:45:53 UTC, Stefan Koch wrote:
> On Tuesday, 4 October 2016 at 01:59:11 UTC, Stefan Koch wrote:
>> On Tuesday, 4 October 2016 at 01:20:01 UTC, Manu wrote:
>>> On 4 October 2016 at 04:21, Stefan Koch via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>> On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler wrote:
>>>>
>>>>>
>>>>> 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
>>>>
>>>> That was my intention.
>>>>>
>>>>> Maybe this idea could also be expanded to template instantiation?
>>>>
>>>>  Oh yes. it is not that more much work :)
>
> A small update on this.
> The POC works rather well ...
> Except for cases of massive template recursion. (binderoo and most of std.traits)
> In such cases a stack overflow occurs inside the prettyPrinter.
>
> I am trying to find a work-around.

The simplest workaround is to run recursion heavy code in a fiber with large stack size (e.g. 64MB).

// before
auto newExpr = expr.ctfeInterpret();  // some recursion heavy code

// after	
Expression newExpr;
	
import core.thread : Fiber;	
new Fiber(
{
     newExpr = expr.ctfeInterpret();  // some recursion heavy code
}, 64 * 1024 * 1024).call();