Visual D 0.50.0-beta1 released

[Bert]

On Friday, 12 July 2019 at 10:06:55 UTC, Rainer Schuetze wrote:
>
>
> On 11/07/2019 01:46, Bert wrote:
>> The first and last are expandable, seems the middle is not 
>> being resolved properly:
>> 
>> -        arr    {length=3 ptr=0x0000028d2cbb60c0}
>> inter[]
>> +        [0]    0x0000028d2cbb3010 {}    inter {main.main.s1}
>>         [1]    0x0000028d2cbb3070 {}    inter
>> +        [2]    0x0000028d2cbb30d0 {}    inter {main.main.s3}
>> 
>> 
>> the 2nd entry is just main.main.s2
>> 
>> 
>> Maybe you could just generate a large array of 
>> interfaces(might try nestings, empty, derived classes, etc).
>
> It's a lot easier to reduce a failing test than to guess what 
> might go wrong, so a test case would be appreciated.
>
> I suspect s2 has a slightly more complicated inheritance tree. 
> The debugger simulates what happens in _d_toObject 
> (https://github.com/dlang/druntime/blob/master/src/rt/cast_.d#L25). Does explicit cast(Object) work on that instance?


No, they are all the same... well, they might not be identical 
because they are different classes but they were copied and 
pasted. They do have some different values for fields but all the 
fields are the same and not complicated at all. They all inherit 
from the same base class and just fill in some of the values with 
the base class doing the heavy lifting.

they are all in the same array so no casting, but this seems 
related to the interface not expanding issue that has previously 
been a problem.

It's really hard to produce a consistent test case that causes 
these problems:

1. I can't upload all my code simply to give a simple case, there 
might be too many dependencies and such.

2. It's not easy to create a simple test case because it may 
actually work. These bugs in Visual D tend to have some "random" 
component to them. Change to much and things start working or 
have some specific thing in a project and things don't work but 
the relation is not obvious or easy to find.

Many times these "bugs" change even within the same program. Add 
a new line and then the behavior changes.

3. Even if I can produce a test case it may work fine on your end 
or fine most of the time.

There seem to be a deep bug in Visual D related to these things 
but it could just be a lot of minor stuff that has bit rotted. 
Ultimately you are going to be the one in the best position too 
deal with them.

I assume you don't use D often enough in complex projects to end 
up with these types of issues or your setup doesn't exhibit them 
as much or it is something specific on my end[Although, these 
errors are too general to be specific to things on my machine].

I imagine what happens is that over time the D compiler and that 
subtly breaks Visual D in various ways and only after some long 
period does someone notice it.

Maybe the best thing to solve most of these issues would be for 
you to maintain a machine, possibly a virtual machine, that has 
just visual D/studio on it(use it to install D with the new 
install features) and download some of the largest maintained D 
projects that you would be most familiar with. Then when someone 
reports something you can use it as a test bed to see if they 
exhibit similar issues.  You might already do something like 
this. What I have noticed though is that Visual D and dmd itself 
seem to work great when the project is small but once one reaches 
some critical mass things start going awry and generally these 
are hard to track bugs(nothing obvious, usually the error 
messages are not informative, etc).


I will try to start keeping a Visual D project for this too. 
Again, what I have noticed though is that it's very hard to get 
these bugs until the project becomes complicated[when I try to 
reduce things enough to remove what seems unrelated to the bug 
then the bug disappears, even things that are unrelated 
programmatically or are used trivially].

		[0]	0x00000281eaa32048 {}	inter
+		[1]	0x00000281eaa32148 {}	inter {main.main.s1}
		[2]	0x00000281eaa32048 {}	inter
+		[3]	0x00000281eaa32148 {}	inter {main.main.s1}
		[4]	0x00000281eaa32048 {}	inter
+		[5]	0x00000281eaa32148 {}	inter {main.main.s1}

It seems that Visual D does not realize the odd elements is a 
resolvable interface.

All these types are nested:

class c
{
     class s1 : inter;
     class s2 : inter;
}


I've tried creating a similar case but it doesn't have the 
problem. In the original code I use meta programming to generate 
the structure, but the much simplified "equivalent" doesn't have 
the problem. So I don't know how to fix it besides given you all 
my code, which I don't want to do and it technically may not help.

All I can say is that that I have an array of interfaces and some 
of the elements are not expandable. It shouldn't matter what 
those objects are, they all come from the same interface and 
Visual D shouldn't have a problem resolving any of them... even 
if they were drastically different.

This suggests a bug in the Visual D code that resolves the type 
for the object from the interface.

Given that previously Visual D would not resolve any interfaces 
this suggests maybe the new code you added recently is buggy/not 
general enough. Although it is working in the simple case.


--------------------------
Ok, after much work reducing to a test case I went from it not 
working to it working ;/

I can't explain why yet except that when I simplify the code past 
a certain point it then works.

ok, well, the reason why it's failing makes no sense. I 
essentially have some members in a class and when I remove the 
members then Visual D enables expansion of the interface.

This is the code, when I delete it, changes everything:

inter foo;
inter Foo() { return foo; }

Yes, that is right, when I remove that code and run the program 
then I can expand the element.

This is exactly what I mean! It makes absolutely no sense. But 
somehow it screws Visual D up.

Once I get the code completely reduced I will post it for your 
amusement... and I'll probably have to post a video proving it is 
doing what I say it is because it will probably work for you.

These types of bugs are the once that the D ecosystem seems to be 
riddled with. It's just a standard getter that is used all over 
the place yet it breaks things.