visuald
visuald copied to clipboard
dlang
Option to hide select module namespace prefixes from symbols?
turkeyman reported this on 2019-06-13T21:16:05Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=19958
CC List
- r.sagitario
Description
So, compared to debugging C++, I'm finding that the fully-qualified names make understanding code a lot harder in a lot of cases. Most of the time when I'm stepping code, all I can see if long namespaces before the panel runs out of horizontal space and truncates.
Consider the callstack view; you can often only see the namespace and not the actual function name (because the namespace is on the left), same story with the 'Type' column on the right of the watch window, you can usually only see the namespace, items in the __vfptr list, the base class members of classes, etc. Basically everywhere a symbol appears, D symbol names are so long, there's a chance it's truncated before you can see the useful bit.
I think when you're iterating in a codebase, you can assume the namespace prefix, so it'd be great if we had some way to specify a set of namespace prefixes that would be removed from symbol names, allowing us to see the useful part more easily?
One challenge is that this mechanic should be project-local, so shouldn't be a VisualD global configuration. Perhaps it could be specified in the project file and fed into the debugger when you launch for that configuration?
Alternatively, it could be a file in the root directory of your project that you commit to source control, like .gitignore or .travis.yml.
r.sagitario commented on 2019-06-15T12:44:41Z
It doesn't look to bad for me, but that very much depends how much screen area you allow the respective windows to have and what your package hierarchy looks like. I remember having similar issues debugging D_Parser in C#, though.
How about dropping common scope information with the fully qualified function name? E.g. when debugging function dmd.root.filename.addExt symbol dmd.root.rmem.mem would be shortened to rmem.mem, and its type to rmem.Mem.
That doesn't work with the functions shown on the callstack. I just noticed that dmd even generates a FQN even for extern(C/C++) function.
turkeyman commented on 2019-06-15T18:32:44Z
Your suggestion sounds like it might be quite elegant. I'd definitely like to try that out!
@TurkeyMan While debugging dmdserver I had a similar thought as you reported here: too much useless display of common namespaces. Cutting a bit of that off should be a simple change. Well, that turned out to be pretty wrong ;)
When "Shorten type names and function names in call stack" is enabled in the debugger options, the module name is now removed when displayed in the type column (there is some guesswork involved in finding the module name). For type names this only happens if it the result is unambiguous, i.e. there is no other type in another scope with the same name.
When applying this to function names and types in the call stack, I noticed that the stack has been displayed by the native engine so far, never using the D expression evaluation. I implemented the appropriate interface just to notice that showing the stack got horrendously slow. This was caused by some data initialization when the evaluator is switched to a new stack frame, but mostly from a bad performance of the DIA API. So I refactored a bit and added a couple of caches to get a similar performance as the native engine for large call stacks. These should also make other operations more responsive.
The call stack now also shows parameter values using the D expression evaluator, including the __debug-hooks. That can make it slow again, as VS unfortunately doesn't only evaluate the visible portion, but the full stack. I am considering disabling function execution for the call stack. What do you think?
You can try it in https://github.com/dlang/visuald/releases/tag/v1.4.1-beta3
Wow, this is from the ark! Very exciting bunch of patches in this release, I'll try them out as soon as I get a moment at my computer...
