www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newCTFE Status April 2018

reply Stefan Koch <uplink.coder googlemail.com> writes:
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!
Apr 08 2018
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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
Apr 12 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Apr 12 2018
parent Guillaume Piolat <first.last gmail.com> writes:
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!
Apr 12 2018