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

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?

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.

Hi,

another beta available: https://github.com/dlang/visuald/releases/tag/v0.50.0-beta3

Changes from 0.50.0-beta2:

- full installer: slightly improve dmd directory names
- updates:
  - fix link to dmd prerelease download
  - wrong update frequency used for DMD
  - check DMD releases with prerelases, too
  - display HTML error
- mago: limit maximum number of elements for an array
- add option -lowmem

Rainer

On 04/06/2019 09:45, Rainer Schuetze wrote:
> Hi,
> 
> new beta2 available: https://github.com/dlang/visuald/releases/tag/v0.50.0-beta2
> 
> 
> Changes from beta1:
> 
> * check and report invalid non-empty DMD/LDC installation folders
> * VC project:
>   - DMD: fix wrong selections for bounds check options
>   - LDC: added -mixin option
>   - added enable -mixin option to autogenerate files according to the
> compilation model
>   - new option for -extern-std=c++xx
> * visualdproj:
>   - Error List: classify warnings and deprecations according to the
> respective options
>   - bugzilla 19930: fix building projects with "&|<>" in directory names
> * mago: fix conditional breakpoints "not supported"
> 
> Rainer
> 
> 
> On 31/05/2019 18:30, Rainer Schuetze wrote:
>> Hi,
>>
>> for the adventurous: I have just released a preliminary version of Visual D with some new major changes:
>>
>> - there is now another installer available that includes DMD and LDC, so no additional setup steps necessary to get you going
>>
>> - now checks for updates for Visual D, DMD and LDC and assists with downloading and installing
>>
>> - experimental: highlight references to the same symbol as the one at the caret (to be enabled in the editor options)
>>
>> - mago debugger extension: better dynamic type handling of classes and interfaces, show exception message
>>
>> Grab it here: https://github.com/dlang/visuald/releases/tag/v0.50.0-beta1
>>
>> Cheers,
>> Rainer
>>

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]

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?

So, after a few compiler bug crashes and a few hours I was able to simplify the entire code to:


module main;

import std.stdio;

interface X { }


interface I : X
{
	ref X[] S();
}


class C : I
{

	private X[] s;
	ref X[] S() { return s; }
	
	Q sQ;

	// Removing this line works, It should have absolutely zero effect
	I c;


	this(I m = null)
	{			
		s ~= new Q;
			
		// Removing this code works
		static if (is(Q : I))
		{
			auto S = new Q;	
			s ~= S;
			sQ = S;
		}
	}

	class Q : I
	{						
		X[] s;
		ref X[] S() { return s; }		
	}

}

void main()
{
	auto c = new C();
	getchar(); // Set BP here and then expand c then s and both the items should be expandable. If not remove one of the lines above and see if they are then expandable.
}

It's quite amazing that removing either of those marked fixes the problem!!!!!!!

The first is a simple field that screws everything up and it's never even used. The second is simply a static if. (also removing sQ used fixes it)


Bear in mind that I had to remove all this from meta code and so it was buried deep inside my original code, which is why it took so long to figure out. This is precisely why it is so hard to provide tests cases. I essentially had to delete all the seemingly unnecessary lines and run each time and verify until the issue resolved... luckily the code did not take too long to compile each time or I'd still be working on it for another few hours or days. This is not the way too solve these problems.

Now, chances are when you run the code it will work... but I have taken video to prove my case that it is not functioning properly. The code should work and there is absolutely no logical reason why the two blocks of code should have any effect on visual D expanding the interfaces.

The code this was reduced from was just a few modules... imagine a more complex program with hundreds of modules and some strange line causing problems like this. It would be worse than having to find a needle in a haystack. Luckily it was only an hour wasted in my life... Hopefully you don't have to waste more than a minute fixing it ;/ This I feel is a similar problem to the BP(not necessarily related by code but by how bizarre they work).

Remember, some elements would be expandable so this is not something that happens all the time. It seems to be 100% repeatable in the simplified code though and also happens for x86 and x64.

It may entirely be a bug in the compiler as I did get a compiler crash when changing removing some code from a mixin that was completely irrelevant. [which I should probably report too if I can go back and reproduce...]

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.

On 21/07/2019 22:34, Bert wrote:
> So, after a few compiler bug crashes and a few hours I was able to simplify the entire code to:
> 
> 
> module main;
> 
> import std.stdio;
> 
> interface X { }
> 
> 
> interface I : X
> {
>     ref X[] S();
> }
> 
> 
> class C : I
> {
> 
>     private X[] s;
>     ref X[] S() { return s; }
> 
>     Q sQ;
> 
>     // Removing this line works, It should have absolutely zero effect     I c;
> 
> 
>     this(I m = null)
>     {
>         s ~= new Q;
> 
>         // Removing this code works
>         static if (is(Q : I))
>         {
>             auto S = new Q;
>             s ~= S;
>             sQ = S;
>         }
>     }
> 
>     class Q : I
>     {
>         X[] s;
>         ref X[] S() { return s; }
>     }
> 
> }
> 
> void main()
> {
>     auto c = new C();
>     getchar(); // Set BP here and then expand c then s and both the
> items should be expandable. If not remove one of the lines above and see
> if they are then expandable.
> }
> 
> It's quite amazing that removing either of those marked fixes the problem!!!!!!!
> 
> The first is a simple field that screws everything up and it's never even used. The second is simply a static if. (also removing sQ used fixes it)
> 
> 
> Bear in mind that I had to remove all this from meta code and so it was buried deep inside my original code, which is why it took so long to figure out. This is precisely why it is so hard to provide tests cases. I essentially had to delete all the seemingly unnecessary lines and run each time and verify until the issue resolved... luckily the code did not take too long to compile each time or I'd still be working on it for another few hours or days. This is not the way too solve these problems.
> 
> Now, chances are when you run the code it will work... but I have taken video to prove my case that it is not functioning properly. The code should work and there is absolutely no logical reason why the two blocks of code should have any effect on visual D expanding the interfaces.

Thanks for reducing the problem. Almost having given up trying to reproduce the issue with a debug build of the debugger extension, I tried the release build and actually had the repro case.

As it turned out, the problem was (again?) a false entry in the class
name cache that was added when an invalid pointer (including null) was
evaluated (and its dynamic was tried to be determined). Stupid bug, but
that happens.

You can try the fixed version of MagoNatCC.dll from https://ci.appveyor.com/project/rainers/mago/build/artifacts

On Tuesday, 23 July 2019 at 20:57:17 UTC, Rainer Schuetze wrote:
>
>
> On 21/07/2019 22:34, Bert wrote:
>> So, after a few compiler bug crashes and a few hours I was able to simplify the entire code to:
>> 
>> 
>> module main;
>> 
>> import std.stdio;
>> 
>> interface X { }
>> 
>> 
>> interface I : X
>> {
>>     ref X[] S();
>> }
>> 
>> 
>> class C : I
>> {
>> 
>>     private X[] s;
>>     ref X[] S() { return s; }
>> 
>>     Q sQ;
>> 
>>     // Removing this line works, It should have absolutely zero effect     I c;
>> 
>> 
>>     this(I m = null)
>>     {
>>         s ~= new Q;
>> 
>>         // Removing this code works
>>         static if (is(Q : I))
>>         {
>>             auto S = new Q;
>>             s ~= S;
>>             sQ = S;
>>         }
>>     }
>> 
>>     class Q : I
>>     {
>>         X[] s;
>>         ref X[] S() { return s; }
>>     }
>> 
>> }
>> 
>> void main()
>> {
>>     auto c = new C();
>>     getchar(); // Set BP here and then expand c then s and both the
>> items should be expandable. If not remove one of the lines above and see
>> if they are then expandable.
>> }
>> 
>> It's quite amazing that removing either of those marked fixes the problem!!!!!!!
>> 
>> The first is a simple field that screws everything up and it's never even used. The second is simply a static if. (also removing sQ used fixes it)
>> 
>> 
>> Bear in mind that I had to remove all this from meta code and so it was buried deep inside my original code, which is why it took so long to figure out. This is precisely why it is so hard to provide tests cases. I essentially had to delete all the seemingly unnecessary lines and run each time and verify until the issue resolved... luckily the code did not take too long to compile each time or I'd still be working on it for another few hours or days. This is not the way too solve these problems.
>> 
>> Now, chances are when you run the code it will work... but I have taken video to prove my case that it is not functioning properly. The code should work and there is absolutely no logical reason why the two blocks of code should have any effect on visual D expanding the interfaces.
>
> Thanks for reducing the problem. Almost having given up trying to reproduce the issue with a debug build of the debugger extension, I tried the release build and actually had the repro case.
>
> As it turned out, the problem was (again?) a false entry in the class
> name cache that was added when an invalid pointer (including null) was
> evaluated (and its dynamic was tried to be determined). Stupid bug, but
> that happens.
>
> You can try the fixed version of MagoNatCC.dll from https://ci.appveyor.com/project/rainers/mago/build/artifacts

That worked! I still find it very odd that it would exhibit it with irrelevant lines of code removed. Was that changing the cached version or something? Remember I basically have several Q's in my program all virtually identical and some would work and others wouldn't.

Could you post some of the code that you fixed(or I guess push it to master) when you get a chance... I'm just curious to what it looks like. While such bugs are very annoying and better coding methods should be used, I imagine that this type of scenario for interface resolution is probably well localized and this would probably be the last bug fix for it? If not maybe some logging could be implemented. Interfaces should always be resolvable so if the code fails it is a bug in Visual D and having it logged in some way might help future cases.

Thanks for the quick fix, I appreciate it!