If either the first or second operand of `range()` may be a string, we
must not exclude the possibility that the result may be an array of
longs.
Closes GH-8131.
While technically legal, this may cause unexpected situations
(in this example, setting an FE_FREE operand to constant null)
and is suboptimal anyway. It's better to preserve the vacuous type
and drop it later (though we currently don't implement this).
When encountering the following SSA graph:
BB1:
#2.T1 [string] = COALESCE #1.CV0($str) [null, string] BB2
BB2:
#5.T1 [string] = QM_ASSIGN string("")
BB3:
#7.X1 [string] = Phi(#2.X1 [string], #5.X1 [string])
FREE #7.T1 [string]
We would currently determine that #7, #5 are dead, and eliminate
the FREE and QM_ASSIGN. However, we cannot eliminate #2, as
COALESCE is also responsible for control flow.
Fix this my marking all non-CV phis as live to start with. This
can be relaxed to check the kind of the source instruction, but
I couldn't immediately come up with a case where it would be
useful.
Replacing the result type in the general case is dangerous,
because not all opcodes support both VAR and TMP. One common case
is the in_array() result being passed to SEND_VAR, which would
have to be changed to SEND_VAL.
Rather than complicating this logic, reduce the scope to only
doing the type replacement for JMPZ and JMPNZ. The only reason
we're doing this in the first place is to enable the smart branch
optimization, so we can limit it to the relevant opcodes. Replacing
the result type may be marginally useful in other cases as well
(as it may avoid reference checks), but not worth the bother.
We should clear the exception *before* we destroy the execute_data.
Add a variation of the test that indirects through another file,
and would crash otherwise.
If the array is empty, then I'd expect that the generator is never left,
and that can be converted to a no-op and the return value would always be `null`.
Make `yield from [];` as efficient as `if (false) { yield null; }`
when opcache's sccp pass is enabled.
Closes GH-5679
After thinking about this a bit more, the code here was too
conservative. We know that everything but an object is going to
throw, so it's sufficient to restrict the type to MAY_BE_OBJECT.
The change in the test is weird but not incorrect, because it
operates on empty inferred types, in which case the code must be
dead (which it is). We should probably add a more explicit removal
of code working on empty types.
Place a pi node on the non-null edge to remove a spurious
undef/null type.
Additionally, adjust the profitability heuristic to be more
accurate if the "other predecessor" writes to the variable.
Ideally this should not just consider the direct predecessors,
but it's sufficient for this case.
This partially addresses bug #79353 by removing the discrepancy
between ?? and ??=.
Dmitry Stogov