Zend: store the zend_type ptr discriminator in a dedicated kind field

[azjezz]

zend_type packs two unrelated things into a single uint32_t type_mask:

1. A bitset of MAY_BE_* flags (bits 0-17). This is genuinely a set: int|string is two bits OR'd together, and union handling relies on that.
2. A discriminator for what type.ptr points at: a zend_string* class name, a const char* literal name, or a zend_type_list*. These are mutually exclusive, but they were encoded as three one-hot bits (22-24) carved out of the same word.

Overloading one word for both meanings has two costs. It is misleading: the discriminator looks like it composes with the mask when it never does. And it is expensive in space that does not exist. The mask is nearly full. Bits 0-21 are MAY_BE_* plus UNION/INTERSECTION/ARENA/ITERABLE, 25-29 are arg-info extra flags, leaving almost nothing. Any future type-system work that needs an inline flag has nowhere to put it, and the discriminator bits were sitting in the middle of that budget.

What this does

Move the ptr discriminator out of type_mask into a dedicated uint32_t kind field on zend_type, and model it as what it actually is: a small enum where exactly one value applies at a time.

typedef struct {
    void *ptr;
    uint32_t type_mask;  /* MAY_BE_* bitset + metadata flags */
    uint32_t kind;       /* discriminates what ptr points at */
} zend_type;

#define _ZEND_TYPE_KIND_NONE         0u  /* ptr is NULL            */
#define _ZEND_TYPE_KIND_NAME         1u  /* zend_string*           */
#define _ZEND_TYPE_KIND_LITERAL_NAME 2u  /* const char*            */
#define _ZEND_TYPE_KIND_LIST         3u  /* zend_type_list*        */

The HAS_* / IS_COMPLEX predicates become plain equality compares instead of bit tests, and the mutation sites assign the field instead of read-modify-writing individual bits.

Cost

On 64-bit the new field lands in padding that already existed after type_mask, so sizeof(zend_type) is unchanged (16 bytes). On 32-bit the struct grows by 4 bytes. kind is copied as part of the struct everywhere a zend_type is copied, including opcache SHM persist and the file cache, so no serialization changes were needed.

[TimWolla]

I'm not seeing any more obvious issues, but can't comment on whether this change is desirable.

[azjezz]

@TimWolla for why i personally wanted this: i was experimenting with a few type additions, literal types, shapes, and negated types. i was able to use the existing 2 spare bits for literals and shapes, but i couldn't implement negated types because there was no space left.

Gina also pointed out on Discord that post-9.0 we could take a few bits back as types get removed. removing resource frees its own bit, and ITERABLE ( which also has a dedicated bit ) is going away too, so that's 2. MIXED already costs nothing today ( it's just all the bits set, MAY_BE_ANY ), and NEVER ( the bottom type, conceptually just 0 ) does still take a dedicated bit, since 0 already means "no type", so that one we could only reclaim with a re-encoding.

so best case post-9.0, assuming we don't add any new types until then, we'd have maybe ~5 free bits give or take. but this is just delaying the problem for no reason, since the 8 bits are already going into padding.

[TimWolla]

Yes, makes sense. I'm just gonna let the engine experts review this and only did a first pass for the clear “code style” problems.