These methods cannot fail the way they are currently designed. They only
call set_client_option which could fail only with wrong arguments. Since
this is an internal call, the arguments should never change. Either way
set_client_option should not cause init to fail.
This deprecates all callables that are accepted by
call_user_func($callable) but not by $callable(). In particular:
"self::method"
"parent::method"
"static::method"
["self", "method"]
["parent", "method"]
["static", "method"]
["Foo", "Bar::method"]
[new Foo, "Bar::method"]
RFC: https://wiki.php.net/rfc/deprecate_partially_supported_callables
Closes GH-7446.
The test contains PII in the base64-encoded part and is way too
complicated to be useful. I'd try to reduce it, but I can't tell
what it's actually supposed to test.
Since Curl 7.72.0, it supports a new parameter
called `CURLINFO_EFFECTIVE_METHOD`, which returns the effect method
in HTTP(s) requests. This is similar to `CURLINFO_EFFECTIVE_URL`.
- https://curl.se/libcurl/c/CURLINFO_EFFECTIVE_METHOD.html
This adds support for CURLINFO_EFFECTIVE_URL if ext/curl is built
with libcurl >= 7.72.0 (0x074800).
Closes GH-7595.
For FETCH_DIM_W etc encode the context it is being used in
(dim, obj, ref or incdec) so we can throw an appropriate error
message for invalid string offset use, in a way that does not
require inspecting neighboring opcodes. The implementation is
similar to the flags used for FETCH_OBJ.
This means that we do not have to be careful about preserving
following opcodes during optimization.
Closes GH-7599.
As a followup to f34114b1fb print
the contents of arrays rather than just a generic "Array" marker.
Also drop the truncation on strings. As we no longer resolve
constants, there should be less concerns about printing very
large strings here. If someone thought it was a good idea to use
a 10k character strings as a default value in code, then it should
be fine for us to print it in reflection as well.
The immediate error here is the nested indexing in write context,
the fact that it's ultimately wrapped in an unset() doesn't matter.
Same as $str[0][0] += 1 will throw "Cannot use string offset as an
array", so should this case.
Even if the object property is incremented afterwards, the
immediate error is the use as object, not the increment.
Also consolidate tests for this error message. Previously they
were spread across a number of bug-specific tests.
FREE_OP_VAR_PTR() is like FREE_OP(), but only frees VAR, rather
than VARs and TMPs. I don't think this distinction makes sense
anymore, as opcodes using FREE_OP_VAR_PTR() generally only accept
VAR or CV. For the cases where other op types are accepted and
only freeing VAR is desired we already have FREE_OP_IF_VAR().
This drops FREE_OP_VAR_PTR(), leaving only FREE_OP() and
FREE_OP_IF_VAR().
In the Enumeration RFC, it states Backed Enums can implement
interfaces, but it was not clear where the backed Enum type
would need to be placed in such situation.
This commit adds a test case for these scenarios.
Signed-off-by: Agustin Gomes <me@agustingomes.com>
Closes GH-7593.
