While our HTTP parser supports upgrade requests, the code using it does
not. Since upgrade requests are only valid for HTTP/1.1 and we neither
support any higher version, nor HTTPS yet, we do not exit early in case
of such requests, i.e. we ignore them, what is allowed by the specs.
We keep the supporting code in case we can meaningfully support upgrade
requests in the future.
Closes GH-7316.
Combine the code for checking whether all dependencies are
available and reporting an error if they are not. Actually store
the loaded deps and then use those when checking for type
availability, instead of looking up the same classes again and
again.
Currently, classes that can't be linked get moved back into the original script
and are not preloaded. As such classes may be referenced from functions that
did get preloaded, there is a preload autoload mechanism to load them at
runtime.
Since PHP 8.1, we can safely preload unlinked classes, which will then go
through usual lazy loading. This means that we no longer need the preload
autoload mechanism. However, we need to be careful not to modify any hash
table buckets in-place, and should create new buckets for lazy loaded classes.
Non-early-bound classes report inheritance errors at the first line
of the class, if no better line information is available (we should
really store line numbers for properties at least...) Early bound
classes report it at the last line of the class instead.
Make the error reporting consistent by always reporting at the
first line.
opaque is used by the htmlentities filter, which means that we
end up trying to free the score value as a pointer. Don't try to
be overly tricky here and simply allocate a separate structure
to hold the number of illegal characters and the score.
If `P->len` is negative (not only when it is `SQL_NULL_DATA`), we must
not go on, because the following code can't deal with that. This means
that the output parameter will be set to `NULL` without any indication
what went wrong, but it's still better than crashing.
Closes GH-7295.
When resolving constants on a dynamically declared class during
preloading, the enum class may not be available. Fail gracefully
in that case.
Possibly we shouldn't be trying to evaluate constants on
non-linked classes at all?
mutable_data may be used for IMMUTABLE classes, internal classes
and to-be-preloaded classes. Check whether the mutable_data
map_ptr is set rather than only the IMMUTABLE flag.
We need to discard objects in the class constants if they happened
to be evaluated during preloading. To allow doing so, we need to
use mutable_data, which will place the evaluated constants into
a separate table.
Same as with property types, we no longer require that all constants
are resolved for preloading to work, it's just an optimization. As
such, drop the forced resolution for include-based preloading and
just keep the optimization.
Having all property types resolved is no longer a hard requirement
for preloading, resolving the types is just an optimization. As
such, drop the special logic that forced loading of property
types when include-based preloading is used. Instead only keep
the code that resolves types based on actually preloaded classes.
Also drop the ZEND_ACC_PROPERTY_TYPES_RESOLVED flag, which is now
nearly useless and takes up flag space...
This adds support for internal enums with the same basic approach
as userland enums. Enum values are stored as CONSTANT_AST and
objects created during constant updating at runtime. This means
that we need to use mutable_data for internal enums.
This just adds basic support and APIs, it does not include the
stubs integration from #7212.
Closes GH-7302.
static_members, mutable_data and static vars in methods are cleaned
up during an earlier shutdown phase (because this has to happen
before we destroy the object store). There is no need to repeat
this cleanup when destroying the classes.
If fast_shutdown is used, then we don't need to destroy static
members at all. If fast_shutdown is not used, then we already
loop over classes to destroy static members and static variables
in methods.