Problem with BP's

[Rainer Schuetze via Digitalmars-d-debugger]

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.