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!

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.

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.

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.

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!
> 
> 
> 

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?

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.
> 

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.

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.

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.