[M3devel] narrow still failing..

[Rodney M. Bates]

On 01/22/2014 02:47 PM, mika at async.caltech.edu wrote:
> Aha so declaring the type as <: ROOT will probably work as a workaround?
>

I'm not sure whether that would do it or not.  In my pared-down case, I had
moved BDD.T and BDD.Root into main, but left the REFANY variables.  That made
the failures go away.

Until it is fixed, I think the best workaround is TYPECASE with a binding:

TYPECASE x
OF BDD.T(b) =>
   Format(b), etc.

This is known to be working now.  You've probably thought about this, but
this way requires only a single runtime type test.  Either TYPECASE without
the binding of b, or ISTYPE, will require an additional recheck of the same
thing when the narrow, implicit or explicit, happens.  I doubt even a
pretty good optimizing compiler could remove this.  For ISTYPE, it would have
to know that the runtime routine (e.g. CheckIsType) was a pure function.  Pretty
unlikely.  Even worse for TYPECASE, where it would have to know a lot about the
relation between CheckIsType and ScanTypecase.

> Thank you for looking into this.
>
> "Rodney M. Bates" writes:
>> Some more info:
>>
>> The front end is generating incorrect narrow code, only
>> where the type T is an unrevealed <: REFANY.  When T and Root
>> are known, it calls RTHooks.CheckIsType for ISTYPE, NARROW,
>> and implicit narrow in an assignment.
>>
>> When opaque, for explicit and implicit narrow, it simply compares
>> the typecode of x to a single typecode (no doubt for T) and demands
>> they be equal.  In this case, the actual allocated type of x is Root,
>> a proper subtype of T.
>>
>> For ISTYPE, it does call CheckIsType even when the types are opaque.
>>
>> The fact that it happens only when the types are opaque lends
>> credibility to the fact that this bug has gone unnoticed at least
>> as far back as PM3.
>