This issue is properly fixed by GH-7121 on master. For older
branches, disable the use of range information in SCCP, to
reduce impact of potentially incorrect ranges.
Make sure that the previous opline is part of the same block,
otherwise it may be non-dominating.
The test case does not fail on PHP-7.4, but I think the general
problem can appear on 7.4 as well, so I'm applying the patch to
that branch.
Function info for curl_exec() incorrect specified that the
function cannot return true. This is already fixed in PHP 8,
as the func info entry was removed there.
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.
For x ? y : z style structures, the live range starts at z, but
may also hold the value of y. Make sure that the refcounting check
takes this into account, by checking the type of a potential phi
user.
If there is a previous use of the new variable in the phi, we need
to NULL out the use chain of the new source we're adding.
Test case is reduced from an assertion failure in the Symfony Demo.
Add db2_execute() to the list of functions accessing the local
scope. Ideally the API wouldn't do that, but it seems most
pragmatic to address this on the opcache side at this point.
We can't just remove the uses, we need to replace uses.
The test case only fails on master with SSA integrity violations,
but I believe the root issue also existed previously.
instanceof_function() requires linked classes. I'm not reusing
unlinked_instanceof() here, because it performs class loading,
which wouldn't be right here, I think.
Resources used as array keys are generally handled by throwing a
notice and converting the resource to the resource handle. The only
exception is the [$resource => null] syntax, where this was treated
as an illegal offset type instead. However, this also only happened
for VM evaluations, the AST evaluator did handle resources correctly.
