Am 04.01.2012, 15:33 Uhr, schrieb Vladimir Panteleev <vladimir@thecybershadow.net>:

On Wednesday, 4 January 2012 at 14:28:07 UTC, Andrei Alexandrescu wrote:

Hmmm, I see that the other way around. D CTFE-generated macros are much easier to debug because you can actually print the code before mixing it in. If it looks like valid code... great.

Paging Don Clugston: would it be feasable to have the compiler remember the source position of every single char/string literal or compile-time-evaluated string expression?

I'm thinking that if the compiler tracks the source of every string/char literal in the source code, all across to any manipulations, debugging CTFE-generated code would be a lot easier - the compiler would emit error messages pointing inside string literals, and debuggers could step inside code in string literals. (The one thing this doesn't allow is allowing debuggers to step through a DSL with no D code in it.)

The naive implementation would store the position of every character, which would blow up the memory usage by about 13 times or so on 32-bit? (For every character, add a struct with 3 fields - char* filename; int line, column). A rope-like structure could cut down on that but possibly drastically complicating the implementation.

Last time I generated big and complex mixin I let the compiler
output mixins to separate files. This gives you nicer debugging
and readable error lines.
https://github.com/D-Programming-Language/dmd/pull/426