On 04.01.2012 15:33, Vladimir Panteleev wrote:
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.
A simpler way to debug CTFE generated code is to dump it to another file
and redirect the debugger to this file.
Here is a patch that does just that, but it is probably not up to date
anymore: http://d.puremagic.com/issues/show_bug.cgi?id=5051#c4
