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.
George Peter Banyard