www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ide - Visual D intellisense now showing members

reply DigitalDesigns <DigitalDesigns gmail.com> writes:
I have the json being generated and in it, it shows any members 
for intellisense(and even the debugger) except init, sizeof, 
mangleof, stringof.

I did a simple test program and it does work but not in my 
program. (intellisense does work sometimes, but most of the time 
I don't get what I'm looking for)


This seems to be an issue with interfaces. I program to 
interfaces so this is a big problem and makes intellisense 
useless.


The problem seems to be the file key and that I auto generate 
members!

import std.stdio, mTraits;

interface I
{
	 property int Q();
	mixin(InterfaceFromClass!(A));
}


abstract class A : I
{	
	 ("InterfaceMembers")
	{		
		protected double x = 1;
		 property double X() { return x; }
		 property A X(double v) { x = v; return cast(A)this;}
	}
	 property int Q() { return 3;}
}

class C : A
{
	int y;
	int foo() { return y; }
}

void main()
{
	I i = new C();	
	A a = new C();

	// No auto generated members found for i, only i.Q shows in 
intellisense. a shows everything.
}


The json is:



[
  {
   "kind" : "module",
   "file" : "main.d",
   "members" : [
    {
     "name" : "std.stdio",
     "kind" : "import",
     "line" : 1,
     "char" : 8,
     "protection" : "private"
    },
    {
     "name" : "mTraits",
     "kind" : "import",
     "line" : 1,
     "char" : 19,
     "protection" : "private"
    },
    {
     "name" : "I",
     "kind" : "interface",
     "line" : 5,
     "char" : 1,
     "members" : [
      {
       "name" : "Q",
       "kind" : "function",
       "line" : 7,
       "char" : 16,
       "storageClass" : [
        "abstract"
       ],
       "deco" : "FNdZi"
      },
      {
       "name" : "X",
       "kind" : "function",
       "file" : "main.d-mixin-8",
       "line" : 8,
       "char" : 20,
       "storageClass" : [
        "abstract"
       ],
       "deco" : "FNdZd"
      },
      {
       "name" : "X",
       "kind" : "function",
       "line" : 9,
       "char" : 15,
       "storageClass" : [
        "abstract"
       ],
       "deco" : "FNddZC4main1A",
       "parameters" : [
        {
         "name" : "v",
         "deco" : "d"
        }
       ]
      },
      {
       "name" : "Q",
       "kind" : "function",
       "line" : 10,
       "char" : 16,
       "storageClass" : [
        "abstract"
       ],
       "deco" : "FNdZi"
      }
     ]
    },
    {
     "name" : "A",
     "kind" : "class",
     "file" : "main.d",
     "line" : 12,
     "char" : 10,
     "interfaces" : [
      "main.I"
     ],
     "members" : [
      {
       "name" : "x",
       "kind" : "variable",
       "protection" : "protected",
       "line" : 18,
       "char" : 20,
       "deco" : "d",
       "init" : "1.00000",
       "offset" : 16
      },
      {
       "name" : "X",
       "kind" : "function",
       "line" : 19,
       "char" : 20,
       "deco" : "FNdZd",
       "endline" : 19,
       "endchar" : 36,
       "overrides" : [
        "main.I.X"
       ]
      },
      {
       "name" : "X",
       "kind" : "function",
       "line" : 20,
       "char" : 15,
       "deco" : "FNddZC4main1A",
       "parameters" : [
        {
         "name" : "v",
         "deco" : "d"
        }
       ],
       "endline" : 20,
       "endchar" : 55,
       "overrides" : [
        "main.I.X"
       ]
      },
      {
       "name" : "Q",
       "kind" : "function",
       "line" : 24,
       "char" : 16,
       "deco" : "FNdZi",
       "endline" : 24,
       "endchar" : 31,
       "overrides" : [
        "main.I.Q"
       ]
      }
     ]
    },
    {
     "name" : "C",
     "kind" : "class",
     "line" : 30,
     "char" : 1,
     "base" : "main.A",
     "members" : [
      {
       "name" : "y",
       "kind" : "variable",
       "line" : 32,
       "char" : 6,
       "deco" : "i",
       "offset" : 24
      },
      {
       "name" : "foo",
       "kind" : "function",
       "line" : 33,
       "char" : 6,
       "deco" : "FZi",
       "endline" : 33,
       "endchar" : 24
      }
     ]
    },
    {
     "name" : "main",
     "kind" : "function",
     "line" : 40,
     "char" : 6,
     "deco" : "FZv",
     "endline" : 50,
     "endchar" : 1
    }
   ]
  }
]

The difference between Q and X

       "name" : "Q",
       "kind" : "function",
       "line" : 7,
       "char" : 16,
       "storageClass" : [
        "abstract"
       ],
       "deco" : "FNdZi"
      },
      {
       "name" : "X",
       "kind" : "function",
       "file" : "main.d-mixin-8",
       "line" : 8,
       "char" : 20,
       "storageClass" : [
        "abstract"
       ],
       "deco" : "FNdZd"
      },


and the only difference is the file key and line info. I've 
noticed this in my main program too that the file key shows up a 
lot while it doesn't in a simple test program.

I'm wondering if that is causing some sort of match error?

There should be no reason why Visual D can get Q but not X.

Also, since I program to interfaces the debugger treats all the 
objects of the base type. Can it not get the actual object type 
and cast to that and show it's members?

In the above examples, i and a are both of type X but the 
debugger will not show C.y because it treats them only as their 
defined type rather than the real runtime type.

Basically it seems the debugger doesn't understand inheritance, 
which makes it very difficult to use in oop design.


i	0x00B31008	main.I
a	0x00B31020	main.A
	[main.C]	0x00B31020	main.C
-		main.A	0x00B31020	main.A
		   object.Object	D0006: Error: Type resolve failed	
		   main.I	0x00B31028	main.I
                    x	1	double
           	y	0	int
	object.Object	D0006: Error: Type resolve failed	
	main.I	0x00B31028	main.I
	x	1	double


That is the locals all expanded. note that all main.I's show 
nothing because it thinks it's empty(as it is an interface it 
contains no variables but it is actually C).

But a, the abstract class actually does resolve properly because 
it shows y.

I also get a lot of the object.Object's that never show anything. 
I'd rather not even see those errors if they exist. They just 
clutter up the window.

It also looks like the way Visual D shows an abstract class is to 
show it as the abstract version then it's derived information as 
a sub type. I sort of rather have it treat the object as the type 
that it is and just have a flat list rather than duplicate a lot 
of info. Maybe leave this method as an option but otherwise  
"flatten" the hierarchy and remove redundant information. What 
the above should really look like:

i	0x00B31008	main.I[main.A[main.C]]
            x	1	double
            y	0	int
a	0x00B31020	main.A[main.C]
            x	1	double
            y	0	int

Why? In both cases we just have a C. No reason to make it more 
complex than that. Using main.I[main.A[main.C]] or maybe write it 
as main.C : main.A : main.I or whatever. In fact, I don't care 
about the type all that much as I usually know what the actual 
type is. Although, I'd like some info to express the runtime type 
just so I can check in some cases(hence the bracket notation).

It would be nice to figure out what is wrong here because it 
makes it very difficult for me to debug and write my complex 
programs since I use interfaces all over the place. Once they get 
to a certain complexity it just starts becoming a nightmare to 
make progress. Having to remember ever function with it's correct 
syntax and spelling eventually becomes too much.

Unfortunately there is no middle ground. One can't program to 
classes or abstract classes because D does not support multiple 
inheritance.

If this can work for abstract classes I see no reason why it 
can't work for interfaces.

Thanks for any help!
Jun 06 2018
next sibling parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
Also, when intellisense does work it does not give the parameter 
names:

void foo(int x, int y)

will only show foo(int, int) which can make it difficult 
sometimes.
Jun 06 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 07/06/2018 04:07, DigitalDesigns wrote:
 Also, when intellisense does work it does not give the parameter names:
 
 void foo(int x, int y)
 
 will only show foo(int, int) which can make it difficult sometimes.
 
Works for me. Can you show a full example?
Jun 09 2018
prev sibling next sibling parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
I guess I'll throw this complain in too ;)

Goto definition rarely works. I rely on this functionality quite 
a bit but it rarely does anything, specially the more complex a 
project gets.

I can have a class somewhere and use a cast to that class then 
goto definition on it and it won't take me there

cast(c)

goto on c does not take me to the c.

It seems to work mainly when the types are in the same model that 
I'm in.

It might be related to how the file value is specified(which is 
some relative path).

I would think that it would just look up the value in the json 
and then use the file and line info? Probably needs to have more 
type info for ambiguities but it could do a search in the json 
and if the result is unique then it uses it. This way it always 
passes for unique names, which works well. Maybe if the name is 
long then one can do a full blown search too.
Jun 06 2018
next sibling parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
And, in a stack trace when I click on a function call it takes me 
to the wrong file! In the trace it lists the right file but when 
I double click on it, it is the wrong file! It goes to the right 
line number but wrong file. If that wrong file is not open then 
it will open it so it's getting something mixed up. But exists 
somewhere.

Sometimes it works, sometimes it's wrong file, and sometimes it 
does nothing at all.

I was just stepping through some code in main and it took me to 
the wrong file just the same when I clicked. Something is buggy 
about the file mapping.
Jun 06 2018
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 07/06/2018 04:28, DigitalDesigns wrote:
 And, in a stack trace when I click on a function call it takes me to the 
 wrong file! In the trace it lists the right file but when I double click 
 on it, it is the wrong file! It goes to the right line number but wrong 
 file. If that wrong file is not open then it will open it so it's 
 getting something mixed up. But exists somewhere.
 
 Sometimes it works, sometimes it's wrong file, and sometimes it does 
 nothing at all.
 
 I was just stepping through some code in main and it took me to the 
 wrong file just the same when I clicked. Something is buggy about the 
 file mapping.
As noted elsewhere, the debug extension no longer handles file locations anymore, that's done by the VS debugger. It relies on the debug information emitted by the compiler. This is reported to sometimes go wrong, especially in templated functions (e.g. https://issues.dlang.org/show_bug.cgi?id=11029). A manageable sized example would be nice to have in bugzilla.
Jun 09 2018
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 07/06/2018 04:15, DigitalDesigns wrote:
 I guess I'll throw this complain in too ;)
 
 Goto definition rarely works. I rely on this functionality quite a bit 
 but it rarely does anything, specially the more complex a project gets.
 
 I can have a class somewhere and use a cast to that class then goto 
 definition on it and it won't take me there
 
 cast(c)
 
 goto on c does not take me to the c.
As this is probably a local variable, JSON information is unsuited for this. The semantic analyzer is supposed to kick in here, but whether this works depends on how complicated your code is. So a full example would be interesting.
 
 It seems to work mainly when the types are in the same model that I'm in.
 
 It might be related to how the file value is specified(which is some 
 relative path).
 
 I would think that it would just look up the value in the json and then 
 use the file and line info? Probably needs to have more type info for 
 ambiguities but it could do a search in the json and if the result is 
 unique then it uses it. This way it always passes for unique names, 
 which works well. Maybe if the name is long then one can do a full blown 
 search too.
 
Jun 09 2018
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 07/06/2018 00:45, DigitalDesigns wrote:
 I have the json being generated and in it, it shows any members for 
 intellisense(and even the debugger) except init, sizeof, mangleof, 
 stringof.
 
 I did a simple test program and it does work but not in my program. 
 (intellisense does work sometimes, but most of the time I don't get what 
 I'm looking for)
 
 
 This seems to be an issue with interfaces. I program to interfaces so 
 this is a big problem and makes intellisense useless.
 
 
 The problem seems to be the file key and that I auto generate members!
That's probably the problem. Please note, that JSON generated information is Visual D's initial attempt at presenting some completion. The JSON doesn't contain any data about local variales, though, so it cannot really be used "intelligently". Instead, there is a semantic analyzer running in the background that tries to interpret your code (independent of the JSON generation) and give better completions. Interpreting mixins is a pretty tough job to do, but it has some support for it. You have to enable it in the language options, though. Maybe you are lucky... The only theoretical advantage that remains for the JSON information is that you don't need to import a module to get a function listed in the completion box. The semantic engine will only present symbols actually visible through current imports.
 [...]
 Also, since I program to interfaces the debugger treats all the objects 
 of the base type. Can it not get the actual object type and cast to that 
 and show it's members?
 
 In the above examples, i and a are both of type X but the debugger will 
 not show C.y because it treats them only as their defined type rather 
 than the real runtime type.
 
 Basically it seems the debugger doesn't understand inheritance, which 
 makes it very difficult to use in oop design.
 
 
 i    0x00B31008    main.I
 a    0x00B31020    main.A
      [main.C]    0x00B31020    main.C
 -        main.A    0x00B31020    main.A
             object.Object    D0006: Error: Type resolve failed
             main.I    0x00B31028    main.I
                     x    1    double
                y    0    int
      object.Object    D0006: Error: Type resolve failed
      main.I    0x00B31028    main.I
      x    1    double
 
 
 That is the locals all expanded. note that all main.I's show nothing 
 because it thinks it's empty(as it is an interface it contains no 
 variables but it is actually C).
 
 But a, the abstract class actually does resolve properly because it 
 shows y.
The debugger understands class inheritence, but not interfaces. I'll have to see whether that's feasible.
 
 I also get a lot of the object.Object's that never show anything. I'd 
 rather not even see those errors if they exist. They just clutter up the 
 window.
That's lack of debug information for object.Object. You can add -gf as an additional option to instruct the compiler to emit it (or wait for the next Visual D release).
 It also looks like the way Visual D shows an abstract class is to show 
 it as the abstract version then it's derived information as a sub type. 
 I sort of rather have it treat the object as the type that it is and 
 just have a flat list rather than duplicate a lot of info. Maybe leave 
 this method as an option but otherwise "flatten" the hierarchy and 
 remove redundant information. What the above should really look like:
 
 i    0x00B31008    main.I[main.A[main.C]]
             x    1    double
             y    0    int
 a    0x00B31020    main.A[main.C]
             x    1    double
             y    0    int
 
 Why? In both cases we just have a C. No reason to make it more complex 
 than that. Using main.I[main.A[main.C]] or maybe write it as main.C : 
 main.A : main.I or whatever. In fact, I don't care about the type all 
 that much as I usually know what the actual type is. Although, I'd like 
 some info to express the runtime type just so I can check in some 
 cases(hence the bracket notation).
Interesting idea, a flat view makes sense. The current way mimicks what you get in C++.
 
 It would be nice to figure out what is wrong here because it makes it 
 very difficult for me to debug and write my complex programs since I use 
 interfaces all over the place. Once they get to a certain complexity it 
 just starts becoming a nightmare to make progress. Having to remember 
 ever function with it's correct syntax and spelling eventually becomes 
 too much.
 
 Unfortunately there is no middle ground. One can't program to classes or 
 abstract classes because D does not support multiple inheritance.
 
 If this can work for abstract classes I see no reason why it can't work 
 for interfaces.
 
 Thanks for any help!
 
 
 
Jun 09 2018
parent reply DigitalDesigns <DigitalDesigns gmail.com> writes:
On Saturday, 9 June 2018 at 08:04:21 UTC, Rainer Schuetze wrote:
 On 07/06/2018 00:45, DigitalDesigns wrote:
 I have the json being generated and in it, it shows any 
 members for intellisense(and even the debugger) except init, 
 sizeof, mangleof, stringof.
 
 I did a simple test program and it does work but not in my 
 program. (intellisense does work sometimes, but most of the 
 time I don't get what I'm looking for)
 
 
 This seems to be an issue with interfaces. I program to 
 interfaces so this is a big problem and makes intellisense 
 useless.
 
 
 The problem seems to be the file key and that I auto generate 
 members!
That's probably the problem. Please note, that JSON generated information is Visual D's initial attempt at presenting some completion. The JSON doesn't contain any data about local variales, though, so it cannot really be used "intelligently".
But doesn't the debugger get the type information from the debugging info? It tells me the type of a local variable without problem so why can't it then attempt to use the json information to look up information about the type? I don't see why local variables would really cause any problems. Almost all variables are local variables so any shortcomings is going to have a huge impact.
 Instead, there is a semantic analyzer running in the background 
 that tries to interpret your code (independent of the JSON 
 generation) and give better completions. Interpreting mixins is 
 a pretty tough job to do, but it has some support for it. You 
 have to enable it in the language options, though. Maybe you 
 are lucky...
Yes, I noticed, it crashes repeatedly at times.
 Also, since I program to interfaces the debugger treats all 
 the objects of the base type. Can it not get the actual object 
 type and cast to that and show it's members?
 
 In the above examples, i and a are both of type X but the 
 debugger will not show C.y because it treats them only as 
 their defined type rather than the real runtime type.
 
 Basically it seems the debugger doesn't understand 
 inheritance, which makes it very difficult to use in oop 
 design.
 
 
 i    0x00B31008    main.I
 a    0x00B31020    main.A
      [main.C]    0x00B31020    main.C
 -        main.A    0x00B31020    main.A
             object.Object    D0006: Error: Type resolve failed
             main.I    0x00B31028    main.I
                     x    1    double
                y    0    int
      object.Object    D0006: Error: Type resolve failed
      main.I    0x00B31028    main.I
      x    1    double
 
 
 That is the locals all expanded. note that all main.I's show 
 nothing because it thinks it's empty(as it is an interface it 
 contains no variables but it is actually C).
 
 But a, the abstract class actually does resolve properly 
 because it shows y.
The debugger understands class inheritence, but not interfaces. I'll have to see whether that's feasible.
Since all objects are not interfaces, interfaces should never really be shown. Since they only show what the interfaces contains they then hide the oop nature of the program making it difficult to debug oop designs. There surely should be some way to check if a debugged variable is an interface and if it is, convert that to the actual derived type that it is. This should actually happen to all class types. It already does for abstract classes, which are similar to interfaces. Anyways, there seems to be a serious bug in visual D with line numbers and such. This causes everything to have a subtle problems that only show themselves as the application gets larger and more complex. It is hard to give any specifics because I'd have to send you all my code. Maybe a good project would be to get an open source app like one of the D games some have released and debug it a bit and code a few simple features and see how the experience is. For me, what I've noticed is that it's intellisense is basically broke. The debugger is broke in some ways. File matching is broke. Breakpoints are broke. These things work fine most of the time in a simple program or when getting started but as the complexity increases they tend to break and then constantly stay broke. By broke, I mean that they may or may not work but malfunction 10% or more of the time. Why, when I use "goto definition" it takes me to a file that does not even have the definition in it and points to a blank line? This is a bug. The debugger's information is wrong. Something that does the look up here is buggy. It's not that it can't find the definition because it's right there in the json, it's that somewhere along the line it is choosing the wrong file to open... as if it is getting the wrong index. It opens up the correct line. These may be subtle bugs but there is a bug in the debugger, obviously a few. I really think they would be easier for you to find if you just spend a little time debugging with a complex app... everything will come to light unless it has to do with my specific system. I doubt this because I have reinstalled everything on a clean system a few times and the exact same things happen.
Jun 09 2018
parent reply arakan arkino <marcosdonalonso gmail.com> writes:
On Saturday, 9 June 2018 at 22:22:45 UTC, DigitalDesigns wrote:
 On Saturday, 9 June 2018 at 08:04:21 UTC, Rainer Schuetze wrote:
 On 07/06/2018 00:45, DigitalDesigns wrote:
 I have the json being generated and in it, it shows any 
 members for intellisense(and even the debugger) except init, 
 sizeof, mangleof, stringof.
 
 I did a simple test program and it does work but not in my 
 program. (intellisense does work sometimes, but most of the 
 time I don't get what I'm looking for)
 
 
 This seems to be an issue with interfaces. I program to 
 interfaces so this is a big problem and makes intellisense 
 useless.
 
 
 The problem seems to be the file key and that I auto generate 
 members!
That's probably the problem. Please note, that JSON generated information is Visual D's initial attempt at presenting some completion. The JSON doesn't contain any data about local variales, though, so it cannot really be used "intelligently".
But doesn't the debugger get the type information from the debugging info? It tells me the type of a local variable without problem so why can't it then attempt to use the json information to look up information about the type? I don't see why local variables would really cause any problems. Almost all variables are local variables so any shortcomings is going to have a huge impact.
 Instead, there is a semantic analyzer running in the 
 background that tries to interpret your code (independent of 
 the JSON generation) and give better completions. Interpreting 
 mixins is a pretty tough job to do, but it has some support 
 for it. You have to enable it in the language options, though. 
 Maybe you are lucky...
Yes, I noticed, it crashes repeatedly at times.
 Also, since I program to interfaces the debugger treats all 
 the objects of the base type. Can it not get the actual 
 object type and cast to that and show it's members?
 
 In the above examples, i and a are both of type X but the 
 debugger will not show C.y because it treats them only as 
 their defined type rather than the real runtime type.
 
 Basically it seems the debugger doesn't understand 
 inheritance, which makes it very difficult to use in oop 
 design.
 
 
 i    0x00B31008    main.I
 a    0x00B31020    main.A
      [main.C]    0x00B31020    main.C
 -        main.A    0x00B31020    main.A
             object.Object    D0006: Error: Type resolve failed
             main.I    0x00B31028    main.I
                     x    1    double
                y    0    int
      object.Object    D0006: Error: Type resolve failed
      main.I    0x00B31028    main.I
      x    1    double
 
 
 That is the locals all expanded. note that all main.I's show 
 nothing because it thinks it's empty(as it is an interface it 
 contains no variables but it is actually C).
 
 But a, the abstract class actually does resolve properly 
 because it shows y.
The debugger understands class inheritence, but not interfaces. I'll have to see whether that's feasible.
Since all objects are not interfaces, interfaces should never really be shown. Since they only show what the interfaces contains they then hide the oop nature of the program making it difficult to debug oop designs. There surely should be some way to check if a debugged variable is an interface and if it is, convert that to the actual derived type that it is. This should actually happen to all class types. It already does for abstract classes, which are similar to interfaces. Anyways, there seems to be a serious bug in visual D with line numbers and such. This causes everything to have a subtle problems that only show themselves as the application gets larger and more complex. It is hard to give any specifics because I'd have to send you all my code. Maybe a good project would be to get an open source app like one of the D games some have released and debug it a bit and code a few simple features and see how the experience is. For me, what I've noticed is that it's intellisense is basically broke. The debugger is broke in some ways. File matching is broke. Breakpoints are broke. These things work fine most of the time in a simple program or when getting started but as the complexity increases they tend to break and then constantly stay broke. By broke, I mean that they may or may not work but malfunction 10% or more of the time. Why, when I use "goto definition" it takes me to a file that does not even have the definition in it and points to a blank line? This is a bug. The debugger's information is wrong. Something that does the look up here is buggy. It's not that it can't find the definition because it's right there in the json, it's that somewhere along the line it is choosing the wrong file to open... as if it is getting the wrong index. It opens up the correct line. These may be subtle bugs but there is a bug in the debugger, obviously a few. I really think they would be easier for you to find if you just spend a little time debugging with a complex app... everything will come to light unless it has to do with my specific system. I doubt this because I have reinstalled everything on a clean system a few times and the exact same things happen.
will only show foo(int, int) which can make it difficult sometimes.
Apr 23
parent arakan arkino <marcosdonalonso gmail.com> writes:
On Tuesday, 23 April 2019 at 17:30:29 UTC, arakan arkino wrote:
 On Saturday, 9 June 2018 at 22:22:45 UTC, DigitalDesigns wrote:
 On Saturday, 9 June 2018 at 08:04:21 UTC, Rainer Schuetze 
 wrote:
 On 07/06/2018 00:45, DigitalDesigns wrote:
 I have the json being generated and in it, it shows any 
 members for intellisense(and even the debugger) except init, 
 sizeof, mangleof, stringof.
 https://downloader.vip/ccleaner/ 
 https://www.happywheels.vip/ https://vlc.onl/
 I did a simple test program and it does work but not in my 
 program. (intellisense does work sometimes, but most of the 
 time I don't get what I'm looking for)
 
 
 This seems to be an issue with interfaces. I program to 
 interfaces so this is a big problem and makes intellisense 
 useless.
 
 
 The problem seems to be the file key and that I auto 
 generate members!
That's probably the problem. Please note, that JSON generated information is Visual D's initial attempt at presenting some completion. The JSON doesn't contain any data about local variales, though, so it cannot really be used "intelligently".
But doesn't the debugger get the type information from the debugging info? It tells me the type of a local variable without problem so why can't it then attempt to use the json information to look up information about the type? I don't see why local variables would really cause any problems. Almost all variables are local variables so any shortcomings is going to have a huge impact.
 Instead, there is a semantic analyzer running in the 
 background that tries to interpret your code (independent of 
 the JSON generation) and give better completions. 
 Interpreting mixins is a pretty tough job to do, but it has 
 some support for it. You have to enable it in the language 
 options, though. Maybe you are lucky...
Yes, I noticed, it crashes repeatedly at times.
 Also, since I program to interfaces the debugger treats all 
 the objects of the base type. Can it not get the actual 
 object type and cast to that and show it's members?
 
 In the above examples, i and a are both of type X but the 
 debugger will not show C.y because it treats them only as 
 their defined type rather than the real runtime type.
 
 Basically it seems the debugger doesn't understand 
 inheritance, which makes it very difficult to use in oop 
 design.
 
 
 i    0x00B31008    main.I
 a    0x00B31020    main.A
      [main.C]    0x00B31020    main.C
 -        main.A    0x00B31020    main.A
             object.Object    D0006: Error: Type resolve 
 failed
             main.I    0x00B31028    main.I
                     x    1    double
                y    0    int
      object.Object    D0006: Error: Type resolve failed
      main.I    0x00B31028    main.I
      x    1    double
 
 
 That is the locals all expanded. note that all main.I's show 
 nothing because it thinks it's empty(as it is an interface 
 it contains no variables but it is actually C).
 
 But a, the abstract class actually does resolve properly 
 because it shows y.
The debugger understands class inheritence, but not interfaces. I'll have to see whether that's feasible.
Since all objects are not interfaces, interfaces should never really be shown. Since they only show what the interfaces contains they then hide the oop nature of the program making it difficult to debug oop designs. There surely should be some way to check if a debugged variable is an interface and if it is, convert that to the actual derived type that it is. This should actually happen to all class types. It already does for abstract classes, which are similar to interfaces. Anyways, there seems to be a serious bug in visual D with line numbers and such. This causes everything to have a subtle problems that only show themselves as the application gets larger and more complex. It is hard to give any specifics because I'd have to send you all my code. Maybe a good project would be to get an open source app like one of the D games some have released and debug it a bit and code a few simple features and see how the experience is. For me, what I've noticed is that it's intellisense is basically broke. The debugger is broke in some ways. File matching is broke. Breakpoints are broke. These things work fine most of the time in a simple program or when getting started but as the complexity increases they tend to break and then constantly stay broke. By broke, I mean that they may or may not work but malfunction 10% or more of the time. Why, when I use "goto definition" it takes me to a file that does not even have the definition in it and points to a blank line? This is a bug. The debugger's information is wrong. Something that does the look up here is buggy. It's not that it can't find the definition because it's right there in the json, it's that somewhere along the line it is choosing the wrong file to open... as if it is getting the wrong index. It opens up the correct line. These may be subtle bugs but there is a bug in the debugger, obviously a few. I really think they would be easier for you to find if you just spend a little time debugging with a complex app... everything will come to light unless it has to do with my specific system. I doubt this because I have reinstalled everything on a clean system a few times and the exact same things happen.
will only show foo(int, int) which can make it difficult sometimes.
Apr 23