Hi Guys,

I have just implemented dynamic cast.
Or rather I have debugged it.

The generated byte-code for dynamic cast itself was correct.
However per function only one dynamic cast would be generated.

To generate my dynamic casts I loop through my type table and look for classes which are dynamic cast targets.
like this
---
bool needDynamicCast(BCType type)
{
  foreach(dc;known_dyncasts)
  {
    if (dc.targetType == type)
       return false;
  }
  return true;
}

what follows is the simplified definition of BCType at the point of the bug

enum BCTypeEnum
{
    u32, i32, Class, Ptr, Struct, Void;
}

struct BCType
{
    BCTypeEnum kind;
    alias kind this;
    uint typeIndex;
}

Because the members exposed by alias this_ed members take priority over the members of the containing struct.
the comparison will only compare the kind of the type.
And ignore the typeIndex.

Which then means that every classType is considered equal  to every other classType.
Which will cause every class to refer to the same dynamic cast, which is only generated for the first dynamic cast encountered.

The Moral of this, if you use any implicitly generated members, stay away from alias this.
chances are minor changes to the contained type make it shadow certain members that it did not shadow before, and in case of auto-generated members you cannot even insert debug_prints to ensure they are being called.

Before I noticed the bug I rewrote a lot of my low-level code (because I thought my code-generation was at fault) introducing even more bugs which I had to fix after I found the real culprit.

Regards,
Stefan

PS. my vacation is over so it will most likely grow silent around newCTFE again.
Rest assured though  that it is not dead and is being worked on!
It's just that my time-budget severely decreased.

See you at dconf!

On Sunday, 8 April 2018 at 09:44:04 UTC, Stefan Koch wrote:
> [ ... ]

And again I find a case which we did not handle for years.
When we directly interpret a function which takes a reference to a static immutable global as parameter.

This global will be full of zeros since newCTFE had no function body to sneak the initialization code into.

This is a close relative of the problem that we have when using functionCalls in the global scope interpretations.

Which I solved via a hack that introduces an invisible wrapping function to do the calls for the arguments in.

However I do remember there being corner-cases which this approach could not solve.
It's time I look for a proper solution.

Cheers,
Stefan

On Thu, Apr 12, 2018 at 06:59:33PM +0000, Stefan Koch via Digitalmars-d wrote: [...]

Good to hear work on newCTFE is still ongoing.  Still can't wait for it to come to fruition.  Keep up the good work!


T

-- 
You have to expect the unexpected. -- RL

On Thursday, 12 April 2018 at 19:40:56 UTC, H. S. Teoh wrote:
> On Thu, Apr 12, 2018 at 06:59:33PM +0000, Stefan Koch via Digitalmars-d wrote: [...]
>
> Good to hear work on newCTFE is still ongoing.  Still can't wait for it to come to fruition.  Keep up the good work!
>
>
> T

+1 very curious how much we will be able to parse at compile-time!