Compile-time generated code... not that nice

[Jarrett Billingsley]

On Sat, May 30, 2009 at 4:42 PM, Ary Borenszweig <ary at esperanto.org.ar> wrote:
> Jarrett Billingsley escribió:
>>
>> On Sat, May 30, 2009 at 3:03 PM, Ary Borenszweig <ary at esperanto.org.ar>
>> wrote:
>>>
>>> I just realized that code generated at compile-time (with string mixins)
>>> is
>>> hard (or impossible) to debug (I mean at runtime, not just at
>>> compile-time).
>>> Do you think it's a big shortcomming of D? How can this be solved?
>>>
>>> Maybe the compiler can generate a file with the contents of a module with
>>> mixins expanded, and use these files as the input to the compiler and
>>> linker, so these can be used in the debugging process.
>>>
>>
>> FWIW templates have more or less the same problem.
>
> More or less... look, if you have:
>
> ---
> template Foo(T) {
>  T someMethod(T x) {
>     x += 4;
>     return x;
>  }
> }
>
> void main() {
>  Foo!(int).someMethod(4);
> }
> ---
>
> If you debug it, if you step into someMethod you'll get to correct lines and
> you'll understand what's going on. But if you do:
>
> ---
> char[] one() {
>  return "x += 4;\n";
> }
>
> char[] two() {
>  return "return x;\n";
> }
>
> mixin("int someMethod(int x) {" ~
>        one() ~
>        two() ~
>       "}";
>
> void main() {
>  someMethod(4);
> }
> ---
>
> Now if you step into someMethod, you'll go to the mixin line, and then
> stepping further you'll get to the "one()" line, but it'll be confusing.
> Even more, if you write more line breaks, like this:
>
> mixin("int someMethod(int x) {\n\n\n\n\n\n\n" ~
>        one() ~
>        two() ~
>       "}";
>
> then when debugging you'll go to lines below the mixin, because the source
> is no longer in sync with the code.
>
> I know this is a contrived example, but at least when debugging
> scrapple/units it happens. :-P
>

Oh I certainly don't disagree with you that string mixins make this
kind of stuff extremely difficult to debug.  It's even difficult for
the compiler to issue reasonable error messages; currently it seems to
issue errors within string mixins at (line of mixin expression + line
within string), which is usually completely bogus.  However, if we're
going to solve the debugging issues with string mixins, we may as well
try to find a solution that would improve the handling of templates in
conjunction with debug info as well.