[M3devel] narrow still failing..

[Rodney M. Bates]

It should be fixed in the head, now.

On 01/23/2014 09:25 AM, Rodney M. Bates wrote:
>
>
> 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.
>>
>
>