Visual D return BP

Bert Bert at gmail.com
Sat Aug 17 20:09:06 UTC 2019


On Saturday, 17 August 2019 at 06:08:43 UTC, Rainer Schuetze 
wrote:
>
>
> On 16/08/2019 23:22, Bert wrote:
>> 
>> 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...
>
> For single cases there is "Step into specific" in the context 
> menu that allows you to select the function to step into, 
> ignoring all others. It doesn't work too well with virtual 
> function dispatch, though.
>
>> 
>> 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.
>
> UDAs are currently not part of the debug info, so it would not 
> be so easy to get that info to the debugger.

Probably a good idea. It will mix in things that probably 
shouldn't be mixed together.

>
>> 
>> 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.
>
> Adding fully qualified functions to "c:\Program Files 
> (x86)\Microsoft
> Visual
> Studio\2019\Community\Common7\Packages\Debugger\Visualizers\default.natstepfilter"
> seems to work. You can also create a similar file in the same 
> folder or
> in "c:\Users\user-name\Documents\Visual Studio 
> 2019\Visualizers". Maybe
> there is also a way to have a similar project local file.
>


That would be nice, I don't have that dir and it probably 
changes. If we could get a project file that can do it then it 
might work really well.

What would be really cool is to have some way to specify BP 
conditions(e.g., if cnt > 3 then break; or if (x) then break).

One can then have different files for different debugging 
cases(save) them if they want.





More information about the Digitalmars-d-ide mailing list