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