On 20.08.2017 20:26, Johnson Jones wrote:
On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote:
On 18.08.2017 00:41, Johnson Jones wrote:
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would say that
there was an error in the symbols for the project.
debugging mixins is not really supported by the compiler. It generates
source filenames that don't exist.
Yes, but in this case, it does exist! Which is why I'm saying it might
be a useful feature!
mixin(import(filename))
is essentially a direct insertion of filename in to the D source.
Even though it internally goes through the mixin analysis of the code,
it passes right through.
So, If VisualD knew that, it could just link up filename in to the
source and allow debugging of it.
If dmd outputted all string mixins to files, then the same logic would
apply.
e.g.,
it would rewrite
mixin("Hello World");
to
mixin(import(temp342.d));
and temp342.d would contain "Hello World".
Or it could just create a special module for it then import that
directly like below, which would probably allow it to nearly work with
Visual D. Visual D would just then have to know what is going on so it
could dive in to the "sub-file".
What I'm getting at is that it seems like very little work would have to
be done to get string mixins to be debuggable... instead of trying to
write some specialized mixin debugger. Dmd and Visual D already do all
the heavy lifting, they just need to communicate with each other enough
to make it happen.
There have been a couple of implementations of this, e.g.
https://github.com/dlang/dmd/pull/426 and the patch in
https://issues.dlang.org/show_bug.cgi?id=5051, but didn't get merged.
