This does a compile time transformation of ``iterable`` into ``Traversable|array`` which simplifies some of the LSP variance handling.
The arginfo generation script from stubs is updated to produce a union type when it encounters the type ``iterable``
Extension functions which do not regenerate the arginfo, or write them manually are still supported by mimicking the compile time transformation while registering the function.
Type Reflection is preserved for single ``iterable`` (and ``?iterable``) to produce a ReflectionNamedType with name ``iterable``, however usage of ``iterable`` in union types will be converted to ``array|Traversable``
* Use arena in DCE instead of multiple alloca()
This requires passing the optimizer context
* Use our do_alloca() instead of alloca()
* Use emalloc in DEBUG builds instead of stack allocations for do_alloca()
This helps detecting that we correctly free do_alloca()
Rather than using a separate hash table for doubles, use the same
biases hash approach we use for everything else. Either way works
fine, but there doesn't seem to be any strong reason to use a
different approach for doubles than we use for other cases.
Rather than keeping track of a separate valid_T set (which must
always be in sync with map_T), use a dummy value in map_T to
denote unallocated temporaries.
If the result has no uses we need to allocate it when visiting the
defining instruction. However, we should still go through the
logic to remove the temporary from the taken map afterwards,
as the temporary can still be reused prior to the defining
instruction.
This seems to be a leftover from when we were storing cache slots
inside literals and had to prevent merging of literals with
incompatible cache slots. Nowadays the LITERAL_* classification
is not actually used for anything, we're only interested in the
number of related literals.
Nowadays we include the content of all the related literals in the
cache key, so DECLARE_CLASS (where both literals cannot be derived
from each other) no longer needs this special case.
I don't think this is strictly necessary, but I think it makes
sense to check this before interpreting opline->op2.num as an
argument number.
This also adds one more has_known_send_mode() check that I had
missed before.
We may sometimes create FETCH_*_R opcodes with VAR type (e.g. if a
FUNC_ARG opcode is converted to BP_VAR_R fetch kind). Make sure we
don't infer overly conservative types in that case.
Pierrick Charron