Paul Dragoonis [Thu, 18 Jun 2020 09:40:40 +0000 (10:40 +0100)]
Removing HTML Functionality from run-tests.php
As discussed on GH-5632, the HTML functionality does not appear
to be in active use. For HTML rendering of test results, it is
suggested to instead use the JUnit integration, in combination
with your favorite JUnit viewer.
Nikita Popov [Fri, 19 Jun 2020 07:27:19 +0000 (09:27 +0200)]
Forbid use of <?= as a semi-reserved identifier
One of the weirdest pieces of PHP code I've ever seen. In terms
of tokens, this gets internally translated to
use x as y; echo as my_echo;
On master it crashes because this "echo" does not have attached
identifier metadata. Make sure it is added and then reject the
use of "<?=" as an identifier inside zend_lex_tstring.
Nikita Popov [Thu, 18 Jun 2020 13:59:32 +0000 (15:59 +0200)]
Un-XFAIL FPM tests
These were XFAILed due to a bug in the log implementation that
caused intermittent failures. However, this issue is supposed to
be resolved in the meantime, so try dropping the XFAIL marker.
The `security_level` stream option is only available as of OpenSSL
1.1.0, so we only set it for these versions. Older OpenSSL versions
do not have security levels at all.
Nikita Popov [Thu, 18 Jun 2020 08:32:33 +0000 (10:32 +0200)]
Migrate some tests to certificate generator
This migrates all the tests using ext/openssl/tests/streams_crypto_method.pem
to the certificate generator, so we can easily adjust needed parameters.
In particular, this makes the cert security level 2 compatible.
However, we still need to downgrade security_level to 1 in a number
of tests, because they are testing TLS < 1.2 connections.
Nikita Popov [Thu, 18 Jun 2020 08:07:45 +0000 (10:07 +0200)]
Remove bug48187.phpt
Saw a spurious failure from this one on azure macos, presumably
the process got interrupted in the middle and waited for more than
one second to resume.
After looking a bit more closely, this test doesn't actually test
what bug #48187 reported, because there is no DateTime::diff()
anywhere to be found. This test was also added speculatively,
because the root cause was never diagnosed, and the problems seems
to have resolved itself at some point.
As such, I'm simply dropping this test, rather than figuring out
how to make it more robust.
In 1999, inline optimization was turned off by default. The commit log indicates this was
done because GCC was running out of memory on some hosts when building the Zend executor.
In 2003, inline optimization was re-enabled by default, but a build option was added to
turn it off if one runs out of memory when building.
Computing hardware has come a long way since 2003 and I doubt that anyone is running out
of memory when building PHP now.
Interestingly, this code set an unused variable called `INLINE_CFLAGS`. It actually
disabled inline optimization by adding -O0 to the build command, not using `INLINE_CFLAGS`.
Just to see how much memory GCC/Make are using when building PHP, I tried building with
successively higher values of `ulimit -v` until it succeeded. Interestingly, while most
of the codebase can be built with about 400MB of memory, ext/fileinfo/libmagic/apprentice.c
requires 1.2GB, doubtless because it includes ext/fileinfo/data_file.c, which is more
than 350,000 lines long. That is with GCC 7.5.0.
Most users get PHP as a binary package anyways, so the question is, are *packagers*
of PHP trying to build on machines with just 1GB RAM? And would they want to package
a PHP interpreter built with *no optimizations*? I can't imagine either being true.
Instead of marking unreachable code with `ZEND_ASSERT(0)`, we introduce
`ZEND_UNREACHABLE()`, so that MSVC which does not consider `assert(0)`
to mark unreachable code does no longer trigger C4715[1] warnings in
debug builds. This may be useful for other compilers as well.
FR #79344: xmlwriter_write_attribute_ns: $prefix should be nullable
The `$prefix` parameter of `xmlwriter_write_element_ns()` and
`xmlwriter_start_element_ns()` is nullable, what allows these functions
to be used instead of their non NS variants. Consequently, we make the
`$prefix` parameter of `xmlwriter_write_attribute_ns()` and
`xmlwriter_start_attribute_ns()` nullable as well.
Even if the length of a maker note does not match our expectations
(either because the maker note is corrupted, or because our
expectations do not quite match reality), there is no need to let
parsing fail; we can still go on parsing the other meta information.
Nikita Popov [Fri, 12 Jun 2020 12:57:08 +0000 (14:57 +0200)]
Use GC stack in nested data removal
We should be doing this anyway to prevent stack overflow, but on
master this is important for an additional reason: The temporary
GC buffer provided for get_gc handlers may get reused if the scan
is performed recursively instead of indirected via the GC stack.
projects / php / log