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.
