debugging mixins

[Stefan Koch via Digitalmars-d]

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