Visual D 0.50.0-beta1 released

[Rainer Schuetze]

On 24/07/2019 08:33, Bert wrote:
> On Tuesday, 23 July 2019 at 20:57:17 UTC, Rainer Schuetze wrote
>> 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.

The bugfix commit is
https://github.com/rainers/mago/commit/9801da089a4b4e9ffa8f1442f4b0aff5852d5fa9?w=1.

The problem was that evaluating the dynamic type of any uninitialized or
null class/interface pointer could overwrite a previously evaluated
entry in the vtbl->class name cache depending on what happens to be in
an uninitialized local variable.

Hopefully the last bug in that area, but you never know. Adding logging
would help diagnosing bugs but would have to be more global.