Visual D intellisense now showing members

[DigitalDesigns]

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.