Visual D 0.50.0-beta1 released
Rainer Schuetze
r.sagitario at gmx.de
Tue Jul 23 20:57:17 UTC 2019
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
More information about the Digitalmars-d-ide
mailing list