Visual D structs/classes not showing in debugging (reprise)

[Rainer Schuetze via Digitalmars-d-debugger]

On 07.08.2017 04:25, Johnson Jones wrote:
> https://ibb.co/kaJAwa
> 
> That shows a screen shot of the behavior. Not sure why some type are not 
> showing while others are. They are all from gtkD. Most seem to be window.
> 
> Looking at window, it looks like the only field defined is
> 
>      /** the main Gtk struct */
>      protected GdkWindow* gdkWindow;
> 
> It would be nice if protected fields were shown.
> 
> The real problem is that it looks like getters and setters are shown to 
> return the data and, of course Visual D has no way to know what is what.
> 
> e.g.,
> 
>      /** the main Gtk struct as a void* */
>      protected override void* getStruct()
>      {
>          return cast(void*)gdkWindow;
>      }
> 
> 
> or
> 
>      public static GType getType()
>      {
>          return gdk_window_get_type();
>      }
> 
> 
> and these are not marked in any way.
> 
> I'm not sure what Visual D can do to help this situation.

When debugging C++, you can call functions in the watch window. I'm 
hoping this will work for D, too, someday. Unfortunately, it seems with 
the Concord debugger integration it needs a very different approach to 
expression evaluation than what is currently used.

A slight complication is that member functions are never zero argument 
function, because the this pointer has to be passed. So it always needs 
to respect the proper ABI to call a function.

> 
> It's obvious to a human that the above functions are effectively 
> wrappers around an internal field.
> 
> I'm not sure if Visual D can determine functions that return non-void 
> and take 0 args(i.e, getters, specially if their name starts with get) 
> and basically treat them as a field and call the function to get their 
> value that is inserted in the list as if it were a field seamlessly?

@property functions would be the appropriate members, though that 
attribute is more or less deprecated.

> 
> If it could, it would at least help fill out the information listed a 
> bit rather than show {}. Then we can parse down through the data 
> structure and see more of whats going on.
> 
> 
> e.g.,
> 
> public static string Name() { return "xyc"; }
> 
> should ultimately, in the locals/watch/autos, be treated as if it were a 
> field of type string with name `Name`.

Not sure why a static function should be considered a field ;) @property 
members would fit in, though.


> The value, of course, can only be 
> gotten by calling the function, which I'm not sure if the debugger can 
> do or not while debugging and sitting on a BP?(it should, since it 
> should know the address and these functions almost surely are safe to 
> call in most cases. If not, it just catches the error and displays it. 
> Obviously the function could do bad things like write to disk, etc.
> 
> Instead, maybe it just list them by name and ignores the value. Maybe 
> double clicking on it then could run the function and insert the data in 
> to the tree.
> 
> Anyways... So close but so far away ;)
> 

See also https://issues.dlang.org/show_bug.cgi?id=16692