PR# 17748 Changing attribute to once-per-object function in SCOOP system causes "illegal value type" panic

After initial compilation where a void-safe SCOOP system is frozen, a
boolean attribute is changed to a once-per-object function and the system
is melted.  System execution then crashes with an "illegal value type" panic.

Added test scoop018 for this incrementality bug.

Run test scoop018.

Fixed in rev#87236 of EiffelStudio 7.0 intermediate release.

`eif_box' is fixed in rev#87235 of EiffelStudio 7.0 intermediate release.

It looks to me like the panic is also due to a bug in routine `eif_box' in
malloc.c.  That routine has a case for SK_REF, so it is trying to correctly
handle a reference that is passed in, but it fails because

   switch (v.type)

should be

   switch (v.type & SK_HEAD)

I noticed a couple of other places that might be incorrect in eif_rout_obj.h,
depending on how they are actually used, but I can't be sure.  These are
places that get the "type" without masking with SK_HEAD.  You should
probably examine them to be sure they are OK:

#define eif_item_sk_type(tuple,pos)             ((EIF_TYPED_VALUE *) (tuple) + pos)->type

#define eif_item_type(tuple,pos)                eif_sk_type_to_type_code(eif_item_sk_type(tuple,pos))

#define rout_tuple_item_copy(t,i,s,j) \
        (*((EIF_TYPED_VALUE *) (t) + i)).item = (*((EIF_TYPED_VALUE *) (s) + j)).item; \
        if (eif_item_sk_type(t,i) == SK_REF) { \
                RTAR((EIF_REFERENCE) t, eif_reference_item(s,j)); \
        }

#define e
....
Output truncated, Click download to get the full message

The problem is that the SK_REF skeleton value returned from the scoop melted attribute access has a melted code flag encoded within, the generated code always checks == SK_REF when it should do a mask with SK_HEAD before doing the check.  The type panic is because for some reason the code always generates a boxing alternative path even though this cannot happen in this scenario, when the SK_REF check fails it tries to box the value which results in the type panic.

The problem is not related to once-per-object functions.  A modified example
that never has any once-per-object functions still causes the same panic.
Commenting out one line in a routine and recompiling (which causes the
routine to be melted) causes the panic to occur.  Freezing the system then
prevents the problem from occurring, so it looks like this may be a
case where incorrect melted code is generated.