Visual D return BP

[Bert]

On Thursday, 15 August 2019 at 18:23:25 UTC, Rainer Schuetze 
wrote:
>
>
> On 11/08/2019 11:47, Bert wrote:
>> if (x)
>>     return
>> 
>> do()
>> 
>> putting a BP on return will cause the BP to hit jump to do on 
>> execution no matter the value of x. This is very annoying ;/
>> 
>> I know this has been brought up before and supposedly it is an 
>> issue with D itself.
>> 
>> Can anything be done about it? It is not sane. No programming 
>> language I have ever used works this way.
>> 
>> 00007FF6BEC8FC6C  cmp         rcx,rax
>> 00007FF6BEC8FC6F  je          foo+48h (07FF6BEC8FC78h)
>> 00007FF6BEC8FC71  pop         rsi
>> 00007FF6BEC8FC72  pop         rbx
>> 00007FF6BEC8FC73  mov         rsp,rbp
>> 00007FF6BEC8FC76  pop         rbp
>> 00007FF6BEC8FC77  ret
>>                 return;
>> 
>>             Do();
>> 00007FF6BEC8FC78  mov         rcx,qword ptr [this]
>> 00007FF6BEC8FC7C  sub         rsp,20h
>> 00007FF6BEC8FC80  mov         rax,qword ptr [rcx]
>> 00007FF6BEC8FC83  call        qword ptr [rax+78h]
>> 00007FF6BEC8FC87  add         rsp,20h
>> 
>> 
>> There is definitely assembly code that should be able to have 
>> a BP put at it to make it all work. The way it works, one is 
>> forced to add junk code simply to get a BP to work correctly 
>> in to a very common programming semantic.
>
> In this example it could work, but the code after the jump is 
> not associated with the return statement, but it is a 
> duplication of the epilog of the function that is considered to 
> have the location of the closing brace. In debug builds the 
> compiler should avoid these kind of optimizations and 
> insert/keep a jump to the end of the function.
>
>> 
>> It seems more like a bug to me, like somehow the BP gets added 
>> after the return rather than before it.
>> 
>> I'm not sure how it couldn't work, you mentioned something 
>> about the D language, optimizations, and Walter refusing to 
>> allow it to work. Surely there is some way to get this to 
>> function correctly?
>> 
>> Thanks
>> 
>
> It's not a problem of the language, but the compiler 
> implementation. I recently filed a bug for this issue when 
> Walter asked for reports: 
> https://issues.dlang.org/show_bug.cgi?id=19985.
>
> Somewhat related: 
> https://issues.dlang.org/show_bug.cgi?id=19989 
> https://issues.dlang.org/show_bug.cgi?id=19991


Thanks, I appreciate it. It's one annoying issue[maybe the 
biggest now, everything else seems to be working well so far, 
although I did experience a crash of VS earlier].

I'm not sure if this can be fixed, but frequently when I step in 
to a function call(F11) any intermediate calls are always stepped 
in to

foo(bar())

F11 to get in to foo will get in to bar also. This can be quite 
annoying and I never remember having this issue in other 
languages. I realize there is no solution since it is impossible 
for the compiler to know if you want to step in to bar too or 
not...

But it seems in some cases other debuggers(such as .NET) somehow 
eliminate common cases that are not necessary but I can't recall 
them off hand.


I wonder if we could not mark a function with some attribute that 
will prevent the debugger from stepping in to it?(would have to 
manually add a BP)

@Mago_StepInto_Ignore void bar() { }

[attr could be aliased by user to something shorter]

and if the attribute exists the the debugger will not step in to 
bar and treat it all as atomic and get directly in to foo.

Or one could create a text file of functions (using fully 
qualified name) that will be ignored. The debugger reads it and 
ignores them like above(this is so the source code doesn't get 
littered with irrelevant code. This might actually be an 
interesting way to interface with the debugger by providing it 
with contextual info on things to do. e.g., one could ignore 
stepping in to whole modules, the phobos, etc.

The reason here is that many functions that act as properties 
using as arguments get stepped in to and one can waste quite a 
bit of time in some instances getting directly to the code they 
want. Some of these functions don't require debugging because 
they are simple so being able to get them ignored.

Ideally it would be supported somehow in the ide itself but I 
don't see that happening(e.g., one could mark the symbols to 
ignore by clicking on them).