Even though `SplStack::unserialize()` is not supposed to be called on
an already constructed instance, it is probably better if the method
clears the stack before actually unserializing.
The place where interface implementation handlers is called is
currently ill-defined: If the class implements interfaces itself,
the handlers for both the parent interfaces and the new interfaces
will be called after all methods are registered (post trait use).
If the class does not implement interfaces, then the parent
interface handlers are called early during inheritance (before
methods are inherited).
This commit moves the calls to always occur after all methods are
available. For userland classes this will be post trait import,
at the time where interfaces get implemented (whether the class
itself defines additional interfaces or not). For internal classes
it will be at the end of inheritance, as internal class declarations
do not have proper finalization.
This allows us to simplify the logic for implementing the magic
Iterator / IteratorAggregate interfaces. In particularly we can
now also automatically detect whether an extension of
IteratorAggregate can safely reuse a custom get_iterator handler,
or whether it needs to switch to the userland mechanism. The
Iterator case continues to rely on ZEND_ACC_REUSE_GET_ITERATOR
for this purpose, as a wholesale replacement is not possible there.
I found what the modifier code does with XOR pretty confusing.
It's just removing the PPP bits...
Also remove an outdated reference to OVERLOADED_FUNCTION.
Make sure all trait method references are converted to absolute
method references in advance. This regresses one error message
that I don't think is particularly valuable.
Currently, trait methods are aliased will continue to use the
original function name. In a few places in the codebase, we will
try to look up the actual method name instead. However, this does
not work if an aliased method is used indirectly
(https://bugs.php.net/bug.php?id=69180).
I think it would be better to instead actually change the method
name to the alias. This is in principle easy: We have to allow
function_name to be changed even if op array is otherwise shared
(similar to static_variables). This means we need to addref/release
the function_name separately, but I don't think there is a
performance concern here (especially as everything is usually
interned).
There is a bit of complication in opcache, where we need to make
sure that the function name is released the correct number of times
(interning may overwrite the name in the original op_array, but we
need to release it as many times as the op_array is shared).
Fixes bug #69180.
Fixes bug #74939.
Closes GH-5226.
Unfortunately, some Webservers (e.g. IIS) do not implement the (F)CGI
specifications correctly wrt. chunked uploads (i.e. Transfer-encoding:
chunked), but instead pass -1 as CONTENT_LENGTH to the CGI
application. However, our (F)CFI SAPIs (i.e. cgi and cgi-fcgi) do not
support this.
Therefore we try to retrieve the stream size in advance and pass it to
`curl_mime_data_cb()` to prevent libcurl from doing chunked uploads.
This is basically the same approach that `curl_mime_filedata()`
implements, except that we are keeping already opened streams open for
the `read_cb()`.
