Visual D 0.50.0-beta1 released

[Bert]

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!