Visual D 0.50.0-beta1 released

Bert Bert at gmail.com
Sun Jul 21 20:34:31 UTC 2019


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










More information about the Digitalmars-d-ide mailing list