Visual D 0.50.0-beta1 released

[Bert]

On Wednesday, 12 June 2019 at 07:21:10 UTC, Rainer Schuetze wrote:
>
>
> On 06/06/2019 22:20, Amex wrote:
>> On Wednesday, 5 June 2019 at 21:26:10 UTC, Rainer Schuetze 
>> wrote:
>>>
>>>
>>> On 05/06/2019 10:41, Amex wrote:
>>>> I've noticed that some interfaces are not expandable in the 
>>>> watches.
>>>>
>>>> Some work some don't, I have no idea what is causing it ;/ 
>>>> The type is being shown as an interface but I can't expand 
>>>> it. It is based off an abstract class and the class that it 
>>>> is does have an attribute added(that isn't added to all the 
>>>> ones that work).
>>>>
>>>> interface X;
>>>> abstract class Y : X
>>>> @nonSerialized class Z : Y;
>>>>
>>>> It may be the attribute.
>>>>
>>>> Yes, it is the attribute, removing it let me expand the item 
>>>> but it crashed visual studio ;/
>>>>
>>>> After the crash I ran again and I couldn't expand ;/ But not 
>>>> sure if that was just something that was messed up.
>>>>
>>>> In any case, definitely seems to be some issue with 
>>>> attributes.
>>>>
>>>
>>> Works here, but as usual I have to guess what your code might 
>>> look like. Please provide complete examples that show the 
>>> issue (and report it at https://issues.dlang.org/ for better 
>>> tracking).
>> 
>> 
>> Unfortunately I can't reduce the code... too much interlinked 
>> stuff. And sometimes it did work. All I know is that it isn't 
>> working 100% for interfaces. It may be random for some 
>> interfaces. All I know is I couldn't expand one interface(no 
>> expander) or some did and they would crash(but pointer was 
>> valid).
>> 
>> If I make a video or screen shot of it showing the behavior, 
>> will that help?
>
> If it has more information, it might help. I wouldn't bet on it 
> though.

Still having issues with interfaces not being expandable. I'm not 
sure if this was suppose to be fixed by now or not.

What's strange is that I have an array of interfaces and some of 
the interfaces are expandable and some are not ;/


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

While the above's s's are not the same, they all are functionally 
the same so there really should be no difference. Either the bug 
is due to some type of odd/even or position dependent issue, is 
"random", or some other issue.

If I run the code again, different entries are expandable. It 
mainly seems to choose the 2nd and 3rd elements though. (after 
repeated runs I never had it like the configuration above)

E.g.,

-		arr	{length=3 ptr=0x0000028d2cbb60c0}	
inter[]
		[0]	0x0000028d2cbb3010 {}	inter {main.main.s1}
+		[1]	0x0000028d2cbb3070 {}	inter
+		[2]	0x0000028d2cbb30d0 {}	inter {main.main.s3}

Seems to be what it is 98% of the time. [Yes, it's always the 
same memory location]