[META] Support PHP 7

I guess we're going to have to make this critical to allow for API changes like #2454447: Split Utility\String class to support PHP 7 (String is a reserved word) needs.

Which I think we more or less have to, not supporting PHP 7 would be very, very unfortunate, especially given that we expect speed improvements for up to 50%...

Yep to me this is critical.

Reference: http://php.net/supported-versions.php

Discussed with @alexpott, @effulgentsia, and @webchick. This is critical because:

• PHP 7 will be released late this year, deprecating all 5.x versions.
• PHP 5.4 is already in security-fix only, and 5.5 will be during D8's stable phase as well.
• We expect at least two years of D8 being the primary stable supported release, plus an LTS after that, and active support for 5.6 will even end before that.
• Drupal 8 is MUCH faster on PHP 7, with performance gains that would qualify for the Critical performance issue criteria.
• Drupal 8 is incompatible with PHP 7 in ways that will require BC breaks to significant public APIs, and we have no way of preserving BC while also supporting PHP 7, making it infeasible to add PHP 7 support before Drupal 9 if we don't make these key changes before releasing Drupal 8.

Finishing a sentence. ;)

How to split Utitlity\String clean-up?
There's separate issue for html #2457781: Use Utility\Html class instead of Utility\String for decodeEntities() function

@dawehner and I agreed that we should do it per target class. So one for the move to Html, and one for the move to SafeMarkup.

Html is just ~30 instances, we should do that first ad then we can mass convert to SafeMarkup.

We both thought that doing it per module or a split like that would take a long time and result in way more conflicts. It will be a huge patch, but also very easy to review, just like that issue was before.

@prateekmehta (don't know if that is his drupal.org username) might already be on it, he asked in IRC.

After applying #2458387: Remove Utility\String class, I can run the unit tests with the following results:

(tests folder)

Strict Standards: Declaration of Drupal\Component\Datetime\DateTimePlus::createFromFormat() should be compatible with DateTime::createFromFormat($format, $time, DateTimeZone $object = NULL) in core/lib/Drupal/Component/Datetime/DateTimePlus.php on line 0
PHPUnit 4.4.2 by Sebastian Bergmann.

Configuration read from core/phpunit.xml.dist

.............................................................   61 / 3079 (  1%)
[...]

Time: 8.08 seconds, Memory: 126.00Mb

There were 5 failures:

1) Drupal\Tests\Component\Utility\SortArrayTest::testSortByTitleElement with data set #1 (array(), array('test'), -4)
Failed asserting that -1 matches expected -4.

core/tests/Drupal/Tests/Component/Utility/SortArrayTest.php:190

2) Drupal\Tests\Component\Utility\SortArrayTest::testSortByTitleElement with data set #2 (array('test'), array(), 4)
Failed asserting that 1 matches expected 4.

core/tests/Drupal/Tests/Component/Utility/SortArrayTest.php:190

3) Drupal\Tests\Component\Utility\SortArrayTest::testSortByTitleProperty with data set #1 (array(), array('test'), -4)
Failed asserting that -1 matches expected -4.

core/tests/Drupal/Tests/Component/Utility/SortArrayTest.php:259

4) Drupal\Tests\Component\Utility\SortArrayTest::testSortByTitleProperty with data set #2 (array('test'), array(), 4)
Failed asserting that 1 matches expected 4.

core/tests/Drupal/Tests/Component/Utility/SortArrayTest.php:259

5) Drupal\Tests\Core\Config\Entity\ConfigEntityBaseUnitTest::testSort
Failed asserting that two variables reference the same object.

core/tests/Drupal/Tests/Core/Config/Entity/ConfigEntityBaseUnitTest.php:447
                                            
FAILURES!                                   
Tests: 3079, Assertions: 33482, Failures: 5.

fails when running on modules/

1) Drupal\Tests\block\Unit\BlockRepositoryTest::testGetVisibleBlocksPerRegion with data set #0 (array(array(true, 'top', 0), array(false, 'bottom', 0), array(true, 'bottom', 5), array(true, 'bottom', -5)), array(array('block1'), array(), array('block4', 'block3')))
Failed asserting that Array &0 (
    'top' => Array &1 (
        0 => 'block1'
    )
    'center' => Array &2 ()
    'bottom' => Array &3 (
        0 => 'block4'
        1 => 'block3'
    )
) is identical to Array &0 (
    'top' => Array &1 (
        0 => 'block1'
    )
    'center' => Array &2 ()
    'bottom' => Array &3 (
        0 => 'block3'
        1 => 'block4'
    )
).

core/modules/block/tests/src/Unit/BlockRepositoryTest.php:112

2) Drupal\Tests\user\Unit\PermissionHandlerTest::testBuildPermissionsSortPerModule
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    0 => 'access_module_a1'
-    1 => 'access_module_a2'
+    0 => 'access_module_a2'
+    1 => 'access_module_a1'
 )

core/modules/user/tests/src/Unit/PermissionHandlerTest.php:199

* DateTimePlus: Needs an issue to adjust the additional arguments so that they match the parent. Looks like we need to find a different way to set those settings. And timezone in our case is currently apparently a string.

* Sort changes again, we already had issues there with changed/implicit/undocumented behavior with HipHop

Also trying to run it for real now. Frontpage works, opened https://github.com/drush-ops/drush/pull/1298, currently looking at

Fatal error: Redefinition of parameter $_ in core/vendor/guzzlehttp/ringphp/src/Client/StreamHandler.php on line 305
Drush command terminated abnormally due to an unrecoverable error.                                                                                                             [error]
Error: Redefinition of parameter $_ in core/vendor/guzzlehttp/ringphp/src/Client/StreamHandler.php, line 305 [9.13 sec, 96.88 MB]

when trying to install..

On the positive side:

Running the tests/ tests:
PHP 5.5 with xdebug: 21s
PHP 5.5: 14s
PHP 7: 8s

Opened https://github.com/guzzle/RingPHP/issues/22, that RingPHP code looks like gibberish to me ;)

Ok, just fixing the first error is enough to make the installer run, the other things seem to be test problems only, so far. I can actually install Drupal then and run simpletests.

And it's blazingly fast.

Running the Entity test group:
PHP 5.5: 2 min 47 sec
PHP 7: 1min 30 sec

drush si standard:
PHP 5.5: 21.64 sec, 78.02 MB
PHP 7: 9.53 sec, 97 MB (Yes, you read that correctly. It does seem to need more memory, though).

As to the test fails:

1. #2461773: SortArrayTest has hardcoded string comparison result values, but these can differ between PHP versions proposes a fix for the first 4 sort test fails
2. #2448765: Element::children sort order undefined and slower than it could be - This makes tests fail in PHP7 may solve the sort issues themselves (see also: https://bugs.php.net/bug.php?id=69158 / http://www.serverphorums.com/read.php?7,1118696)
3. #2457405: DateTimePlus violates substitution principle of DateTime. Make it support PHP 7 discusses DateTimePlus

From a "I'm upgrading my module" POV it's much more user-friendly to have a single change record that consolidates all related PHP 7 changes, rather than 7-8 CRs you have to find (this information is also relevant to module upgrades, not just core).

As a result, took the String one at https://www.drupal.org/node/2457593 and am repurposing it for housing all of the relevant renames/relocations.

We should test Drupal 7 at some point also, to see where it's at with PHP 7. (Although from reading the above issues my guess is that it'll be easier to get working there than with Drupal 8.)

Updated child issues.

Attached is the output of running all tests. I'm looking at those failures now, quite a few are easy fixes (some easy fatal error fixes, a few tests failed with out of memory errors).

So far, twice something extremely weird happend and the autoloader stopped working. I also had one segfault in those tests.

Ok, and attached are some obvious fixes. Setting to needs to review to give testbot a go, we can set back to active and open a separate issue for them. Some errors are pretty strange, a few I guess are related to the sorting problems. Error handling isn't fixed yet with #2463285: Support PHP7 EngineExceptions in the error handler. array_count_values() in a lot of locale/language tests is somehow drunk.

Didn't look at the migrate fails yet, seem to be all the same problem.

Doing another test run now, with those fixes.

+++ b/core/modules/node/src/Tests/NodeAccessGrantsCacheContextTest.php
@@ -65,7 +65,7 @@ protected function setUp() {
    */
-  protected function assertCacheContext(array $expected) {
+  protected function assertUserCacheContext(array $expected) {
     foreach ($expected as $uid => $context) {
       if ($uid > 0) {

We introduced the same method in WebTestBase, but it works differently and has different arguments. This is actually not PHP 7 related, I just noticed it in the qa.drupal.org test results too, because I was looking for the next problem...

Found no database prefix for test ID errors are also not related to PHP 7. Those are phpunit tests in the Drupal\$module\Tests namespace, they should be in Drupal\Tests\$module.

And here are fresh test results. Looks much better already

* For a few tests, 512MB memory is not enough
* Those php related errors continue to get weird. all migrate tests that fail are because of the same reason. array_keys() says that d7_node_type exists in both $migrations and $id_mappings for example for MigrateCckFieldRevisionTest. $id_mappings['d6_node_type'] works, $migrations['d6_node_type'] gives an undefined index notice.

The best part? This works:

-      $migration = $migrations[$migration_id];
+      foreach ($migrations as $id => $migration) {
+        // WTF PHP7, you drunk?
+        if ($id === $migration_id) {
+          break;
+        }
+      }

Performance: Test run duration: 21 min 40 sec with concurrency 8.

PHP7 seems to be really good at efficiently using all the CPU it can get its hands on. This is an i7-3770K CPU @ 3.50GHz, 4 cores, 8 threads. idle cpu is almost constantly below 5%, wait is below 1%, mysql process is running at 80-90% (of one thread). Will run the same on PHP 5.5 to have a reference.

Side-note: I opened #2464817: A few PHPUnit tests are not in the correct namespace for the Found no database prefix for test ID errors.

Back to active, nothing to review (review was for bot)

+++ b/core/modules/node/src/Tests/NodeAccessGrantsCacheContextTest.php
@@ -65,7 +65,7 @@ protected function setUp() {
-  protected function assertCacheContext(array $expected) {
+  protected function assertUserCacheContext(array $expected) {

Oh, hah, this is because WebTestBase recently also got a assertCacheContext() method, I bet, and this test extends WebTestBase.

EDIT: @Berdir already said exactly this in #25. I should read everything first and then start writing a comment :/

PHP7 seems to be really good at efficiently using all the CPU it can get its hands on. This is an i7-3770K CPU @ 3.50GHz, 4 cores, 8 threads. idle cpu is almost constantly below 5%, wait is below 1%, mysql process is running at 80-90% (of one thread). Will run the same on PHP 5.5 to have a reference.

Wow! PHP7++

Ok, created #2465005: PHP Strict Standards in NodeAccessGrantsCacheContextTest for the strict stuff (not php 7 specific but tagged it anyway) and #2465009: Fix fatal errors in rest and views with PHP 7 for the fatal errors

Btw, I did run the tests with PHP5.5: Test run duration: 51 min 20 sec

Not all tests completed with 7, but still, nice...

Here's the test output for D7 if anyone is interested in looking at that. I guess the error handling is one issue that will need to be backported for sure.

Tip: grep -v "0 fails" and grep -v "0 exceptions" in that file to find failures.

Update from the PHP7 front ;)

We've been debugging those array errors together with @ircmaxell and confirmed it is a PHP bug. Opened a bug report: https://bugs.php.net/bug.php?id=69371

Looks like someone found a fix with a patch, I will test that asap.

php7 issue https://bugs.php.net/bug.php?id=69371 is fixed and committed :)

It is, nice. Attached are the test results with the patch applied. Not too much left. I've also attached a filtered version (created with grep -v ' passes '

From looking at that file, the remaining test fails are:

* Drupal\ckeditor\Tests\CKEditorTest 2 fails
* Drupal\comment\Tests\CommentPagerTest 2 fails
* Error handling, we already have #2463285: Support PHP7 EngineExceptions in the error handler for that.
* Drupal\config\Tests\SchemaCheckTraitTest 1 fail
* 3 tests fail with an out of memory, even after raising the memory limit to 768M. This has to be a bug. Two of those happened in core/vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/Compiler/ServiceReferenceGraphNode.php on line 60, that smells like an endless loop to me...
* The array_count_values() warning in the language/locale tests. I really hoped that would be fixed with the same patch, but apparently not. We need to try and isolate that, so that we can open another bug report.
* Drupal\system\Tests\Menu\LocalTasksTest 2 fails
* 1 fail in Drupal\migrate_drupal\Tests\d6\MigrateFileTest and the MigrateDrupal6Test has a fatal error.
* Drupal\search\Tests\SearchCommentTest 1 fail and another one in Drupal\search\Tests\SearchConfigSettingsFormTest
* Drupal\system\Tests\Session\SessionHttpsTest also fails in PHP5, so that's not a PHP7 bug.
* Looks like we also need a pull request for Symfony: core/vendor/symfony/validator/Symfony/Component/Validator/Constraints/Null.php is a reserved keyword now. interesting that this didn't show up earlier and only in one test.

I would suggest we open up issues for each of those problems and discuss them in detail there. If you want to help and have PHP7 installed, pick one of those problems, create an issue and try to find out more about the test fail. Or create a pull request for symfony, that doesn't even need PHP7, my name suggestion would be NullConstraint or so.

* 3 tests fail with an out of memory, even after raising the memory limit to 768M. This has to be a bug. Two of those happened in core/vendor/symfony/dependency-injection/Symfony/Component/DependencyInjection/Compiler/ServiceReferenceGraphNode.php on line 60, that smells like an endless loop to me...

Note: The Service Reference Graph Nodes came up several times in my memory profiling. I suspected a memory leak, but could not proof it, so maybe something is wrong there that just shows more prominent in PHP 7.

* Drupal\system\Tests\Menu\LocalTasksTest 2 fails

This should be fixed in #2448765: Element::children sort order undefined and slower than it could be - This makes tests fail in PHP7, but is in itself a larger problem.

Confirmed, LocalTasksTest is fixed by that and apparently also CommentPagerTest, SearchConfigSettingsFormTest and SearchCommentTest!

Forgot about that issue, thanks for the reminder.

The migrate test fails are also strange, can't reproduce the test fail in MigrateFileTest anymore. Did run it at least 100 times and it didn't fail. And the MigrateDrupal6Test passes actually and only after that gives me that error and I think that's the test that causes the segfault that I've seen before.

PR submitted for Symfony issue, may take a while to get in as NullConstraint is inconsistent with the other constraints and they may go with something like Nil or None. They'll also need to rename the True and False constraints.

If others want to follow the PR: https://github.com/symfony/symfony/pull/14228

ircmaxell just pinged me that drunk php is no longer drunk. If you can update your builds things should be better.

@neclimdul what's the commit that fixed it? Is it this one or a later one?

https://git.php.net/?p=php-src.git;a=commit;h=b6aeab1b9177f4f6b89e7c1553...

Yes, that's the fix. The test results in #34 are already with that patch applied.

It would be awesome if someone could update the issue summary, with an overview of the remaining test tails and existing issues (if existing about them), e.g. those that are fixed by the uasort issue grouped together.

#41: Nice!

Fun fact: Now Drupal terminology is part of PHP tests (https://git.php.net/?p=php-src.git;a=blob;f=ext/standard/tests/array/bug...)

#2448765: Element::children sort order undefined and slower than it could be - This makes tests fail in PHP7 is fixed now, so we are almost there now for PHP7 :).

Add support for session.uploadprogress since uploadprogress PECL extension doesn't compile for PHP 7 and the developers of it said they are considering deprecating it.

Thanks.

Updated the issue summary to list the remaining issues. Starting to look into them now.

Latest results. A few tests that I failed to list before, added to the issue summary.

* Drupal\system\Tests\Installer\InstallerTest 13 passes 5 fails 1 exceptions
* Drupal\system\Tests\Theme\ThemeTest 64 passes 1 fails
* Drupal\config\Tests\SchemaCheckTraitTest 4 passes 1 fails

Looking at some tests a bit closer...

SchemaCheckTrait is also an array order problem it seems:

Fail      Other      SchemaCheckTraitT   69 Drupal\config\Tests\SchemaCheckTrai
    Value array (
      'config_test.types:boolean' => 'non-scalar value but not
    defined as an array (such as mapping or sequence)',
      'config_test.types:new_key' => 'missing schema',
      'config_test.types:new_array' => 'missing schema',
    ) is identical to value array (
      'config_test.types:new_key' => 'missing schema',
      'config_test.types:new_array' => 'missing schema',
      'config_test.types:boolean' => 'non-scalar value but not
    defined as an array (such as mapping or sequence)',
    ).

Opened a bug report for the segfault: https://bugs.php.net/bug.php?id=69411

And another one for the array_count_values() problem: https://bugs.php.net/bug.php?id=69413

Nice, the array_count_values() bug has already been fixed: https://bugs.php.net/bug.php?id=69413 ! The reason was that the array keys were by reference.

Latest test runs. Not much left, but having some randomness going on I think.

Also only 1 test still failing with 758M max memory, the others might be must below that, no idea, will test again with lower max.

Some tests didn't fail, the array_count_values() stuff is resolved, but a few new failing tests. Haven't updated the issue summary yet.

Ok, InstallerTranslationTest is another segfault, this time in apache, but also somehow related to pcre_jit, added a comment to https://bugs.php.net/bug.php?id=69411

Opened #2469169: SchemaCheckTraitTest should use assertEqual(), not assertIdentical()

#2463285: Support PHP7 EngineExceptions in the error handler is actually fixing the ErrorHandlerTest.

So, the segfault in the migrate test is actually a curl shutdown thing. Which means we can work around it because there is only a single migrate test that does such a request and that is easy to convert: #2469269: Don't use a form submission to check the password in MigrateUserTest

Are return types also planned for Drupal?

@ivanjaros If we allowed return types we would break compatibility with PHP 5.

3 issues down, updating fix section of issue summary.

We are getting close!

Can we do a new test run and see which test fails/exceptions are left? I'd do this myself but my PHP7 setup seems broken...

Discussed with @berdir and @alexpott.

• #2455465: Add mod_php7 check to htaccess is a normal bug and #2455455: Unicode requirements should check *_encoding for 5.6+ is a major bug. Both of them could be fixed in a patch release and neither prevent Drupal from working entirely on the relevant versions.
• The out of memory failures and the random fails should be filed as majors.
• The upstream issue in Symfony for Null.php is critical for Drupal 8 (though it's not our issue). I'm keeping this issue as critical until that is resolved. Once it is, let's confirm that issues get filed for everything else, and then we can downgrade this to major for tracking.

So, I've been trying to get new test results, but it is currently segfaulting for me in the installer and every web test, opened https://bugs.php.net/bug.php?id=69464

Tracked down the class that is causing it with help from @ircmaxell to Symfony\\Component\\DependencyInjection\\Compiler\\ServiceReferenceGraphNode, that might be related to the out of memory exceptions, so if we can fix this, we might fix those too....

Yeah, that is the class that showed up in my memory profilings, too ...

Quick update on the PHP7 front, I've worked with dmitry so that he can reproduce the segfault, had some issues there but we eventually managed it.

He's looking into it, he said he found a few issues that he needs to fix and he will update the issue when he did that. Until then, we're blocked here.

Hm, not looking too good right now.

There's apparently a new problem with opcache that results in errors and broken pages, see https://bugs.php.net/bug.php?id=69484, and I've also been seeing some new segfaults. No idea if it's related to the garbage collector changes or not.

Not much to do here except pushing the symfony issue at the moment.

I'll do another test run without xp to get the current status.

Here are the latest results.

Output:

$ php7 core/scripts/run-tests.sh --url http://d8/ --concurrency 8 --all > ../php7_results7.txt
Segmentation fault (core dumped)
Segmentation fault (core dumped)
*** Error in `/usr/local/bin/php7': munmap_chunk(): invalid pointer: 0x00000000022b6f40 ***
Aborted (core dumped)

Didn't look into the segfaults thrown by run-tests.sh yet, but I've also got some on the apache site, backtraces for those are in bt.txt.

They should add Drupal's test suite to PHP xD :-D. Seems we find more bugs than their own ...

Yeah ;)

BTW, the out of memory errors *are* gone, just like I hoped. So we are making progress.

Didn't HHVM at some point even included the entire Drupal test suite as part of their test?

@dawehner: they still do. Results are here :

http://hhvm.com/frameworks/

99,98% passing on 2015-04-16

Yeah, but that just includes unit tests...

Ok, so apparently @dmitry found the bug that was causing those, or most of those segfaults.

I had one more segfault in apache during Drupal\comment\Tests\CommentPreviewTest, and the symfony Null problem, everything else passed. I've tried to reproduce the segfault, but it only happened once so far, repeated that test a few times but it didn't happen again.

PHP 7 testing worked for a brief time for Rules 8.x testing, but fails now again https://travis-ci.org/fago/rules/jobs/59745335

Drush site install triggers the following error:

Original

EngineException: Cannot pass parameter 4 by reference in Drupal\Core\Extension\ExtensionDiscovery->sort() (line 321 of /home/travis/build/fago/drupal-8.0.x-dev/core/lib/Drupal/Core/Extension/ExtensionDiscovery.php).

Drupal\Core\Extension\ExtensionDiscovery->sort(Array, Array)
Drupal\Core\Extension\ExtensionDiscovery->scan('profile')
install_begin_request(Object, Array)
install_drupal(Object, Array)
drush_call_user_func_array('install_drupal', Array)
drush_op('install_drupal', Object, Array)
drush_core_site_install_version('testing', Array)
drush_core_site_install('testing')
_drush_invoke_hooks(Array, Array)
drush_command('testing')
drush_dispatch(Array)
Drush\Boot\BaseBoot->bootstrap_and_dispatch()
drush_main()

Disabling PHP 7 testing on Rules for now.

bug report on php.net about this: https://bugs.php.net/bug.php?id=69532

Ah, good to know, so it seems that the PHP 7 version on Travis CI is slightly out of date and not really built nightly :-(

Latest test results. I had new test fails in Drupal\update\Tests\UpdateContribTest and Drupal\config\Tests\ConfigFormOverrideTest, however, the test results are not stable and vary between runs.

I haven't been able to reproduce ConfigFormOverrideTest at all, and UpdateContribTest sometimes passes and sometimes fails with different amount of fails:

$ php7 core/scripts/run-tests.sh --url http://d8/ --repeat 10 --concurrency 8 --class "Drupal\update\Tests\UpdateContribTest,Drupal\config\Tests\ConfigFormOverrideTest"

Drupal test run
---------------

Tests to be run:
  - Drupal\update\Tests\UpdateContribTest
  - Drupal\config\Tests\ConfigFormOverrideTest

Test run started:
  Wednesday, April 29, 2015 - 21:40

Test summary
------------

Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\update\Tests\UpdateContribTest                        142 passes   7 fails   1 exceptions             
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\update\Tests\UpdateContribTest                        175 passes  12 fails                            
Drupal\update\Tests\UpdateContribTest                        180 passes  13 fails                            
Drupal\update\Tests\UpdateContribTest                        198 passes                                      
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\update\Tests\UpdateContribTest                        198 passes                                      
Drupal\update\Tests\UpdateContribTest                        198 passes                                      
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
Drupal\update\Tests\UpdateContribTest                        198 passes                                      
Drupal\update\Tests\UpdateContribTest                        198 passes                                      
Drupal\update\Tests\UpdateContribTest                        198 passes                                      
Drupal\update\Tests\UpdateContribTest                        198 passes                                      

Test run duration: 1 min 6 sec

Other than those, the symfony Null class is still the only one that failing.

@berdir
So what happens if you look at the actual failures inside UpdateContribTest, is there a clear start where they begin to fail?

I wasn't able to reproduce reliably. I did another run, this time, Drupal\migrate_drupal\Tests\d6\MigrateBookTest failed with an apparent fatal error but it passed. Similar to the migrate test that we've seen earlier. But no crash dump that I could see. Also not reproducible.

The symfony PR is tagged Ready, so should be merged soon I hope. I think we can move this down to major then. I'll continue to do test runs with PHP7 to find problems and eventually track down these random fails but I think that doesn't need to be critical.

Almost there, I just tested Beta 10 on my machine with (when it did let compile) and without Uploadprogress PECL extension and without, it doesn't take session.uploadprogress as replacement.

This is what I get (see files)

Please open a feature requests to add support for that and link it in the issue summary. The first and primary goal of this issue is to get our tests passing, not to support new API's from PHP7. Having an upload progress bar is not blocking the release of Drupal 8.

Here's the Symfony Validator PR for fixing the Null/True/False constraints: https://github.com/symfony/symfony/pull/14228

Just talked with Fabien Potencier in person and he was in favor of leaving BC in 2.3 (but making Symfony compatible by default) and deprecating in 2.7.

He also said he would probably be able to take a look at that before the end of the week! :)

So the goal is within reach!

https://github.com/symfony/symfony/pull/14228 is in 2.3 now! :)

Now we just need to wait for it to be forward-ported to 2.6 and for the deprecation PR to go in for 2.7.

Talked with alexpott regarding the update to 2.6.7 and we agreed we just do that as part of #2489122: Get rid of calls to deprecated API calls. and #2470693: Upgrade to Symfony 2.7.0

Aw, just when I thought we're done.

Did run the tests again, got 4 new segfaults, they're all in file related tests:

Drupal\migrate_drupal\Tests\d6\MigrateUserPictureFileTest
Drupal\file\Tests\RemoteFileSaveUploadTest
Drupal\file\Tests\SaveUploadTest
Drupal\file\Tests\FileFieldDisplayTest

Opened a bug report: https://bugs.php.net/bug.php?id=69643

I also had a views (Drupal\views\Tests\Plugin\DisplayPageTest) test looping for 20min, haven't been able to reproduce when running just that test.

The PHP bug report from #89 has a comment saying that it can't be reproduced.

Yes, I saw that. Can anyone else try to run those tests?

I did a full test run locally on DrupalCI with sqlite and the web-7 container.. with not so good results :( Here's the list of failing tests:

Drupal\system\Tests\Cache\ApcuBackendUnitTest                  0 passes                           
FATAL Drupal\system\Tests\Cache\ApcuBackendUnitTest: Found no database prefix for test ID 80. (Check whether setUp() is invoked correctly.)

Drupal\system\Tests\Database\ConnectionTest                   24 passes   1 fails   1 exceptions

Segmentation fault (core dumped)
FATAL Drupal\system\Tests\Database\SchemaTest: test runner returned a non-zero error code (139).

Segmentation fault (core dumped)
FATAL Drupal\file\Tests\FileFieldDisplayTest: test runner returned a non-zero error code (139).

Segmentation fault (core dumped)
FATAL Drupal\file\Tests\RemoteFileSaveUploadTest: test runner returned a non-zero error code (139).

Segmentation fault (core dumped)
FATAL Drupal\file\Tests\SaveUploadTest: test runner returned a non-zero error code (139).

Drupal\system\Tests\Module\InstallUninstallTest              1408 passes  19 fails

Segmentation fault (core dumped)
FATAL Drupal\system\Tests\Path\AliasTest: test runner returned a non-zero error code (139).- Found database prefix 'simpletest835973' for test ID 793.

Drupal\Tests\block\Unit\BlockRepositoryTest                    1 passes   1 fails

Drupal\Tests\Core\Config\Entity\ConfigEntityBaseUnitTest      20 passes   1 fails

Drupal\Tests\user\Unit\PermissionHandlerTest                   3 passes   1 fails

Fatal error: Cannot use Symfony\Component\Validator\Constraints\Null as Null because 'Null' is a special class name in /var/www/html/core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/NullConstraint.php on line 10
FATAL Drupal\system\Tests\TypedData\TypedDataTest: test runner returned a non-zero error code (255).

What version was that exactly? php --version?

More or less consistent with what I'm seeing.

* apcu is obvious, that extension simply doesn't exist yet for PHP7.

* the segfault for the 4 file related tests, same as i had but the php guys apparently can't reproduce.

* the symfony fatal error, should get fixed when we update to symfony 2.7.

The others are new...

Updated my web container images to the most recent ones (built a few hours ago according to this page: https://registry.hub.docker.com/u/drupalci/web-7/builds_history/175477/), and three of those are now passing so I will remove them from the list in the comment above.

This is the PHP version for the test run in #94 (I cannot bring back the old images and get the version for #92 though..)

sudo -u www-data php --version
Command created as exec id 9aa412b1
PHP 7.0.0-dev (cli) (built: May 21 2015 06:07:15) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies

Ok, i think I tracked this down, see my updated comment in https://bugs.php.net/bug.php?id=69643

In short, it fails somehow if an integer is passed in as a curl postfield. No idea why not more tests are failing, maybe the combination of that and a CurlFile?

This means that we could work around this on our side and get the tests passing if we have to, but let's see what response I get, I assume that someone who knows about PHP internals should be able to fix it with the provided information...

Yay, that curl segfault got fixed !

I'm still seeing one segfault that might be new in Drupal\migrate_drupal\Tests\d6\MigrateFieldTest.

I'm also seeing two new failing tests as well, CommentStatisticsTest and InstallUninstallTest. Looking into those now. And of course still the symfony Null class, but that should be fixed by the end of the month when 2.7 is released.

* CommentStatisticsTest fails randomly.
* MigrateFieldTest segfaults sometimes.. but only when I run tests with --concurrency 8. number might not be relevant, but I can't make it fail in gdb even when getting creative and running it multiple terminals parallel.
* InstallUninstallTest seems to fail reliable. And takes 2m50s. Wondering how slow that is on PHP 5.

And the problem there is #2456025: PHP warnings in PHP 5.6 because of always_populate_raw_post_data ini setting. The check that was added there needs an additional condition to ignore PHP 7 since that setting no longer exists there. Should be a trivial patch.

Ok, I was able to get a core dump from the segfault above. Turns out it's the same one as I've seen in the previous run, but as written, it only happens when running tests with concurrency.

Updated https://bugs.php.net/bug.php?id=69643 with my findings (last comment), will have bug @laruence again tomorrow ;)

I created the issue for this. #2496943: Add condition to ignore PHP 7 on rest requirements check

I recently switched to the new drupalci containers for the SQLite and PostgreSQL bots and wonder if it would make sense to also setup a daily bot doing PHP7 testing? If so, I can do that after my holiday in ten days or so...

If you have resources to do that, sure that would be great. We already have some reports from @amateescu above with DrupalCI 7.x.

php7 test runs are actually about twice as fast as php5, so it shouldn't take that long, just 26 minutes for me with --concurrency 8 :)

Okay, thanks @berdir! Should be mostly just copy and pasting some scripts, so no problem and it's on my agenda now. BTW 26 minutes is very impressive! I never made it under 50 minutes with PHP5 on a powerful XEON box! Really curios to see the actual drupalci results :)

I was to curios and the setup took only some minutes, so here we go: PHP-7 Bot. Wow, just wow! Same setup but more than twice as fast as PHP-5, just 23 minutes!
Please note that some exceptions are bot related and may not be caused by PHP-7 itself and I can't guaranty working daily updates for now as I'm going for holiday :)

Thanks!

InstallUninstallTest is fixed now, TypedDataTest is fixed with #2470693: Upgrade to Symfony 2.7.0, the segfaults got fixed with a recent PHP commit. I can't reproduce any of the other failing tests in your bot, I guess that's what you meant.

Considering to downgrade this to major, to keep tracking it and eventually figure out those random concurrency related segfaults, but I don't think something like that needs to block the 8.0.0.

Thoughts?

Agreed, no critical API changes left that we need to do for PHP 7 before the Drupal 8.0 release.

Nice, really great work berdir and others!

Impressive work, really :)

Awesome! Thanks for pushing this forward so actively! :)

Updated IS with testbot link

There are some phpunit fails on PHP7

1) Drupal\Tests\Core\Config\Entity\ConfigEntityBaseUnitTest::testSort
Failed asserting that two variables reference the same object.
/home/travis/build/jibran/drupal/core/tests/Drupal/Tests/Core/Config/Entity/ConfigEntityBaseUnitTest.php:454
2) Drupal\Tests\block\Unit\BlockRepositoryTest::testGetVisibleBlocksPerRegion with data set #0 (array(array(true, 'top', 0), array(false, 'bottom', 0), array(true, 'bottom', 5), array(true, 'bottom', -5)), array(array('block1'), array(), array('block4', 'block3')))
Failed asserting that Array &0 (
    'top' => Array &1 (
        0 => 'block1'
    )
    'center' => Array &2 ()
    'bottom' => Array &3 (
        0 => 'block4'
        1 => 'block3'
    )
) is identical to Array &0 (
    'top' => Array &1 (
        0 => 'block1'
    )
    'center' => Array &2 ()
    'bottom' => Array &3 (
        0 => 'block3'
        1 => 'block4'
    )
).
/home/travis/build/jibran/drupal/core/modules/block/tests/src/Unit/BlockRepositoryTest.php:112
3) Drupal\Tests\user\Unit\PermissionHandlerTest::testBuildPermissionsSortPerModule
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
 Array (
-    0 => 'access_module_a1'
-    1 => 'access_module_a2'
+    0 => 'access_module_a2'
+    1 => 'access_module_a1'
 )
/home/travis/build/jibran/drupal/core/modules/user/tests/src/Unit/PermissionHandlerTest.php:199

See https://travis-ci.org/jibran/drupal/jobs/65281019 for more details.

Hmm, we had those before in #15

Yeah, but they definitely don't fail with run-tests.sh, weird.

It might be related to some weird visual behavior that I've seen. For example, the order of the columns in the test overview table is inverted when you search with JS. I have no idea how that is possibly related to PHP, but it definitely only happens when I'm running PHP7.

Note: This issue isn't done, or it would be marked as fixed :) It not being critical anymore just means that, to the best of our knowledge, all changes that require us to change API's to be compatible with PHP7 are done. PHP7 isn't released yet, almost every time I did run the tests there were some new segfaults and I'm sure more will show up before it's released.

@bzrudi: Is it possible to update your container so that it's using the latest PHP7 version? It still seems to be reporting the segfaults that should have been fixed shortly before you provided your bot.

I just updated and did run the unit tests and I'm seeing quite a list of unit test fails. Will look into the more closely in the next days.

@berdir I just updated to latest PG images today and think I can update PHP-7 later too, let's see :)

Also, as an FYI, I've updated the roles behind Drupal VM to allow relatively simple configuration of PHP 7 (at this time, alpha 2, using Remi's repo) on CentOS—see PHP 7 on Drupal VM for more info. You can also build from source to test with PHP HEAD, but it's a lot quicker to build from packages if you're just testing things out.

D8 seems to work pretty well (from an end-user perspective), but I did find a segfault when trying to use drush si to install Drupal 8 HEAD.

Did a new test run, seeing lots of errors. Will investigate why exactly later.

One thing I noticed in BackendChainUnitTest is that the clone in prepareItem() doesn't work.. the first time it's coming in, ->data is a serialized string.. on the next call, it's not. So it looks like a bug in clone.

@berdir I updated to latest PHP-7 image yesterday, unfortunately it seems totally broken and causes every third test or so to segfault :( Will try another update later this week but maybe we will already see the new drupalci infrastructure ready within the next days?

Yeah, don't worry.

Can you check what exact version/build you have? I noticed that i had a segfault during the installer with the version that I built on 27th june. I built it again yesterday for my test run and then that segfault was gone again. Still something very broken as commented above.

@berdir

# docker exec b15ffda924f1 php --version
PHP 7.0.0-dev (cli) (built: Jun 25 2015 20:46:40) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies

New phpunit fails on PHP7 https://travis-ci.org/jibran/drupal/jobs/69380174.

Opened https://bugs.php.net/bug.php?id=69996 for that problem.

#123: woah!

I also just wanted to mention that I've been seeing issues with PHP 7.0.0alpha2 in a few different environments with D8 HEAD. I know alpha2 is a little out of date, but things like drush site-install and the general install process seem to be the most annoyingly error-prone parts of getting Drupal 8 going on PHP 7—and those are the things that will quickly turn people off from the attempt to get it working at all (thus making people prone to statements like 'PHP 7 isn't stable' or other FUD).

Hopefully as PHP's tagged releases get more stable, but I think one thing we might want to focus a little extra effort on is making sure site installation works as well as possible—a lot of the efforts in this particular issue seemed laser-focused on fixing unit tests and some simpletests (which is still extremely important, of course!).

#125: I think our simpletests test the Installer enough for basic functionality.

Of course manual testing is important, too.

This issue came up in today (10 July 2015) critical issues discussion meeting. Lot of people are doing testing own there own or as @Berdir pointed out http://d8php7bot.erwanderbar.de/. It'd be nice to have a dedicated issue just for PHP 7 testing so I created #2530640: PHP 7 testing issue. The idea is to get Drupal CI involved in that issue so that we can regularly test Drupal 8 on PHP 7 and fix the fails or report the bugs to PHP7.

Progress report. The PHP 7 bug with cloning reported above has been fixed. Currently doing a new test run.

Found #2531028: Null migrate destination is a reserved keyword in PHP 7 .

Still seeing a fair amount of exceptions, especially in installation related tests. Also a segfault in UncaughtExceptionTest. Hoping that #2505315: Catch PHP7 Throwable objects instead of BaseExceptions in the error handler will help with that.

Additionally identified #2531042: Undefined string index 0 in WebTestBase::getAbsoluteUrl() in PHP 7 and that all installer tests have a similar notice in template_preprocess_html(). Might be the same issue if we can find the real reason, so not posting an issue yet.

The segfault in UncaughtExceptionTest is kinda random it seems.

#2531258: Improve \Drupal\Tests\user\Unit\PermissionHandlerTest::testBuildPermissionsSortPerModule

Here's the latest news from the PHP 7 front ;)

@neclimdul is working on fixing unit tests:
* #2533222: Fix ConfigEntityBaseUnitTest
* #2533168: Fix BlockRepositoryTest
* #2531258: Improve \Drupal\Tests\user\Unit\PermissionHandlerTest::testBuildPermissionsSortPerModule

I also found out why I was never seeing them when running all the tests: #2534104: simpletest_script_run_phpunit() does not use detected/configured php binary to run phpunit tests

The noisy migrate destination Null class has been fixed, so we're down to a bunch of installer test that have some PHP notices and a handful of other tests that have fails/exceptions. ErrorHandlerTest should be fixed by #2505315: Catch PHP7 Throwable objects instead of BaseExceptions in the error handler.

This is apparently not a issue that you can let sit for a while, the PHP developers clearly like to change (and break) things ;)

This is apparently not a issue that you can let sit for a while, the PHP developers clearly like to change (and break) things ;)

Hi pot, meet kettle. ;D

Thanks so much for keeping on top of these, Berdir! Glad to hear we're down to the last few issues. I looked at the two that were RTBC but they looked more framework manager-y to me, but just a general show of support for this awesome initiative. :)

Just did a check for critical compatibility issues with PHP 7 Migration Assistant Report. This may be helpful but I am not sure how to interpret the results.

2015-07-28T11:04:14+05:00
Scanning /var/www/d8/core
Including file extensions: php
Processed 1052483 lines contained in 9049 files.
Processing took 56.044023990631 seconds.

# critical
#### /var/www/d8/core/modules/views/src/Plugin/views/style/Mapping.php
* variableInterpolation
 * Line 89: `        $this::$mapping[$key]['#filter']($field_options);`

#### /var/www/d8/core/vendor/doctrine/annotations/tests/Doctrine/Tests/Common/Annotations/DocParserTest.php
* reservedNames
 * Line 1118: `class True {}`
 * Line 1120: `class False {}`
 * Line 1122: `class Null {}`

#### /var/www/d8/core/vendor/doctrine/common/lib/Doctrine/Common/ClassLoader.php
* variableInterpolation
 * Line 225: `                } else if ($loader[0]::$loader[1]($className)) { // array('ClassName', 'methodName')`

#### /var/www/d8/core/vendor/symfony/validator/Constraints/False.php
* reservedNames
 * Line 20: `class False extends IsFalse`

#### /var/www/d8/core/vendor/symfony/validator/Constraints/Null.php
* reservedNames
 * Line 20: `class Null extends IsNull`

#### /var/www/d8/core/vendor/symfony/validator/Constraints/True.php
* reservedNames
 * Line 20: `class True extends IsTrue`

Thanks, that is useful.

The variable interpolation thing is interesting, wondering if we have no tests for that. We did have a bug in views that was fixed a while ago, see #2465009: Fix fatal errors in rest and views with PHP 7. I think this is the same problem.

The symfony classes are just an unused BC layer, so that's fine, and we don't care about running those doctrine tests, so that's fine too.

This report is made with PHP 7 Compatibility Checker.

The same as previous but without issues from contributed modules code.

Shoot I forgot about the Uniform Variable Syntax RFC(https://wiki.php.net/rfc/uniform_variable_syntax). That's interesting, I wonder why we haven't run into that.

Issue for the fix in our code: #2542872: Fix variable interpolation to be PHP 7 Compatible

FWIW

PHP 7.0.0 Beta 3 Released
http://php.net/archive/2015.php#id2015-08-06-1

Ok, time for some updates. We had a nasty assert related php bug that was fixed in record time: #2547715: Cannot access protected property $this->storage on Install inside SqlContentEntityStorageSchema::.

Then, in #2531042: Undefined string index 0 in WebTestBase::getAbsoluteUrl() in PHP 7, @alexpott pointed out that the notices in the installer are caused by a behavior change of substr, and it was fixed upstream in Symfony.

Did another run with PHP 7.0.0-dev (cli) (built: Aug 8 2015 12:04:23) (included the patch from the above issue)

Then did a composer update to get symfony 2.7.3 which contains the fix for the installer notice problem. Actually wanted to the test run with that but messed up.

Anyway, I did run just the failing tests with that Drupal\comment\Tests\Migrate\d6\MigrateCommentTest,Drupal\config\Tests\ConfigFormOverrideTest,Drupal\config\Tests\LanguageNegotiationFormOverrideTest,Drupal\config\Tests\ConfigInstallProfileUnmetDependenciesTest,Drupal\system\Tests\Installer\DistributionProfileTest,Drupal\system\Tests\Installer\InstallerEmptySettingsTest,Drupal\system\Tests\Installer\InstallerExistingDatabaseSettingsTest,Drupal\system\Tests\Installer\InstallerExistingInstallationTest,Drupal\system\Tests\Installer\InstallerExistingSettingsNoProfileTest,Drupal\system\Tests\Installer\InstallerExistingSettingsTest,Drupal\system\Tests\Installer\InstallerLanguagePageTest,Drupal\system\Tests\Installer\InstallerTest,Drupal\system\Tests\Installer\InstallerLanguageDirectionTest,Drupal\system\Tests\Installer\SingleVisibleProfileTest,Drupal\system\Tests\Installer\InstallerTranslationMultipleLanguageForeignTest,Drupal\system\Tests\Installer\InstallerTranslationMultipleLanguageKeepEnglishTest,Drupal\system\Tests\Installer\InstallerTranslationMultipleLanguageTest,Drupal\system\Tests\Installer\InstallerTranslationTest,Drupal\system\Tests\Installer\StandardInstallerTest,Drupal\migrate_drupal\Tests\d6\MigrateCckFieldValuesTest,Drupal\rdf\Tests\Field\LinkFieldRdfaTest,Drupal\rdf\Tests\Field\NumberFieldRdfaTest,Drupal\system\Tests\System\AdminTest,Drupal\system\Tests\System\IndexPhpTest,Drupal\system\Tests\System\SystemAuthorizeTest,Drupal\taxonomy\Tests\Migrate\d6\MigrateVocabularyEntityDisplayTest,Drupal\update\Tests\UpdateUploadTest

And the result of that was quite promising:

Drupal\config\Tests\ConfigInstallProfileUnmetDependenciesTes   9 passes                                      
Drupal\comment\Tests\Migrate\d6\MigrateCommentTest            26 passes                                      
Segmentation fault (core dumped)
Drupal\config\Tests\ConfigFormOverrideTest                    18 passes                                      
FATAL Drupal\comment\Tests\Migrate\d6\MigrateCommentTest: test runner returned a non-zero error code (139).
- Found database prefix 'simpletest979095' for test ID 1775.
Drupal\system\Tests\Installer\DistributionProfileTest         18 passes                                      
Drupal\config\Tests\LanguageNegotiationFormOverrideTest       22 passes                                      
Drupal\system\Tests\Installer\InstallerEmptySettingsTest      16 passes                                      
Drupal\system\Tests\Installer\InstallerExistingDatabaseSetti  16 passes                                      
Drupal\system\Tests\Installer\InstallerExistingInstallationT  26 passes                                      
Drupal\system\Tests\Installer\InstallerExistingSettingsNoPro  15 passes                                      
Drupal\system\Tests\Installer\InstallerExistingSettingsTest   15 passes                                      
Drupal\system\Tests\Installer\InstallerLanguagePageTest      208 passes                                      
Drupal\system\Tests\Installer\InstallerTest                   20 passes                                      
Drupal\system\Tests\Installer\SingleVisibleProfileTest        18 passes                                      
Drupal\migrate_drupal\Tests\d6\MigrateCckFieldValuesTest      32 passes                                      
Segmentation fault (core dumped)
FATAL Drupal\migrate_drupal\Tests\d6\MigrateCckFieldValuesTest: test runner returned a non-zero error code (139).
- Found database prefix 'simpletest352088' for test ID 1794.
Drupal\rdf\Tests\Field\LinkFieldRdfaTest                      33 passes                           36 messages
Drupal\system\Tests\Installer\InstallerLanguageDirectionTest  26 passes                                      
Drupal\system\Tests\Installer\InstallerTranslationMultipleLa  62 passes                                      
Drupal\system\Tests\System\IndexPhpTest                        6 passes                                      
Drupal\rdf\Tests\Field\NumberFieldRdfaTest                    56 passes                           16 messages
Drupal\taxonomy\Tests\Migrate\d6\MigrateVocabularyEntityDisp  11 passes                                      
Segmentation fault (core dumped)
FATAL Drupal\taxonomy\Tests\Migrate\d6\MigrateVocabularyEntityDisplayTest: test runner returned a non-zero error code (139).
- Found database prefix 'simpletest948066' for test ID 1800.
Drupal\system\Tests\System\SystemAuthorizeTest                17 passes                                      
Drupal\system\Tests\Installer\InstallerTranslationMultipleLa 100 passes                                      
Drupal\system\Tests\Installer\InstallerTranslationMultipleLa 111 passes                                      
Drupal\system\Tests\Installer\InstallerTranslationTest        74 passes                                      
Drupal\system\Tests\System\AdminTest                         167 passes  14 fails   6 exceptions             
Drupal\system\Tests\Installer\StandardInstallerTest           29 passes                                      
Drupal\update\Tests\UpdateUploadTest                          89 passes                                      

Test run duration: 38 sec

So, filtering out the passes again, we are left with some segfaults and fails in AdminTest:

Segmentation fault (core dumped)
FATAL Drupal\comment\Tests\Migrate\d6\MigrateCommentTest: test runner returned a non-zero error code (139).
- Found database prefix 'simpletest979095' for test ID 1775.
Segmentation fault (core dumped)
FATAL Drupal\migrate_drupal\Tests\d6\MigrateCckFieldValuesTest: test runner returned a non-zero error code (139).
- Found database prefix 'simpletest352088' for test ID 1794.
Segmentation fault (core dumped)
FATAL Drupal\taxonomy\Tests\Migrate\d6\MigrateVocabularyEntityDisplayTest: test runner returned a non-zero error code (139).
- Found database prefix 'simpletest948066' for test ID 1800.
Drupal\system\Tests\System\AdminTest                         167 passes  14 fails   6 exceptions    

Oh, and one phpunit test fail but it looks like that fails in PHP 5 as well, but not with simpletest?

1) Drupal\Tests\accept_header_routing_teste\Unit\Routing\AcceptHeaderMatcherTest::testNoRouteFound
Failed asserting that exception message 'No route found for the specified formats application/json text/xml' contains 'No route found for the specified formats application/json text/xml.'.

Opened #2548061: Fix Drupal\Tests\accept_header_routing_teste\Unit\Routing\AcceptHeaderMatcherTest::testNoRouteFound

was able to get a backtrace on one of the migrate segfaults. Filed a php.net issue https://bugs.php.net/bug.php?id=70242

FYI the drupalci bots are now running the latest (Aug 18th) php 7 build, and the jobs are structured such that it will use the latest we have. It's not fully automated, but its really a one button step to refresh to the latest php7 - so if anybody ever needs newer php 7 builds on the testbots, let us know in #drupal-infrastructure or file an issue in the drupal.org/project/infrastructure issue queue and we'll update them. We're waiting on docker hub to fix an issue with triggering remote builds before it can just 'always be the latest'

That's good enough I think. This is only an issue while PHP7 is still in development, once there is a stable release, we can probably stick to that.

https://bugs.php.net/bug.php?id=70272 fixed the bug from #143 and Mixologic is rebuilding to make sure we have the fix in drupalci. Says it should be available in ~30min.

I probably should have just waited later in the day. We now have daily php7 builds, so tests will be running off of a build from sometime the day before. If for some reason there is a hot new commit that you cant wait to get your hands on in 7.0.0-dev, we can still build it on demand too.

Slowly widdling away at PHP bugs and narrowing down failures. Finding fewer and fewer that are on our side which is good but makes them harder.

https://bugs.php.net/bug.php?id=70295 Seems to be the cause of the AdminTest failure. That test calls the one place in all of core that user_save_cookie is called and that is the only reference to setrawcookie in core... Why do we use it? Don't know but thanks to it we've found another php7 segfault.

I hope Drupal gets a prize for all these weird segfaults we've triggered.

I hope Drupal gets a prize for all these weird segfaults we've triggered.

:) :)

PHP 7 RC1 is out - http://php.net/archive/2015.php#id2015-08-21-1

Saw a couple of newsworthy things in the php7 universe and thought I'd call them out here to see if we wanted to do anything:

APCu is passing the test suite for php7:
https://twitter.com/krakjoe/status/637681709606170624

There is a file based opcache in php7 as well:
https://tideways.io/profiler/blog/dodge-the-thundering-herd-with-file-ba...

I know we have some tests that depend on apcu, should we be testing d8 with apcu + file based opcaches? (Since we'll invariably reveal bugs with the implementations)

related, #2554065: Fix APC test for PHP 7 has been sitting around for awhile. forgot to post it here.

PHP7.0.0 RC 2 is now out - http://php.net/archive/2015.php#id2015-09-04-1

The following four fails could use dedicated issues opening for them:

From https://www.drupal.org/pift-ci-job/42111

testMissingDependencyCustomErrorHandler
fail: [Browser] Line 143 of core/modules/system/src/Tests/System/UncaughtExceptionTest.php:
HTTP response expected 418, actual 500

fail: [Other] Line 144 of core/modules/system/src/Tests/System/UncaughtExceptionTest.php:
Raw "Oh oh, flying teapots" found

fail: [Other] Line 148 of core/modules/system/src/Tests/System/UncaughtExceptionTest.php:
Raw "The website encountered an unexpected error." not foun

Update.Drupal\system\Tests\Update\UpdatePostUpdateTest
✓		- runUpdates
✗	
doSelectionTest
fail: [Other] Line 35 of core/modules/system/src/Tests/Update/UpdatePostUpdateTest.php:
Raw "8001 -   Normal update_N() function. First update.Second update.Test1 update.Test0 update." found
✗	
testPostUpdate
fail: [Other] Line 59 of core/modules/system/src/Tests/Update/UpdatePostUpdateTest.php:
Value array (
  0 => 'update_test_postupdate_post_update_first',
  1 => 'update_test_postupdate_post_update_second',
  2 => 'update_test_postupdate_post_update_test1',
  3 => 'update_test_postupdate_post_update_test0',
) is identical to value array (
  0 => 'update_test_postupdate_post_update_test0',
  1 => 'update_test_postupdate_post_update_test1',
  2 => 'update_test_postupdate_post_update_second',
  3 => 'update_test_postupdate_post_update_first',
).

fail: [Other] Line 63 of core/modules/system/src/Tests/Update/UpdatePostUpdateTest.php:
Value array (
  0 => 'block_post_update_disable_blocks_with_missing_contexts',
  1 => 'update_test_postupdate_post_update_first',
  2 => 'update_test_postupdate_post_update_second',
  3 => 'update_test_postupdate_post_update_test1',
  4 => 'update_test_postupdate_post_update_test0',
) is equal to value array (
  0 => 'block_post_update_disable_blocks_with_missing_contexts',
  1 => 'update_test_postupdate_post_update_test0',
  2 => 'update_test_postupdate_post_update_test1',
  3 => 'update_test_postupdate_post_update_second',
  4 => 'update_test_postupdate_post_update_first',
).

fail: [Other] Line 103 of core/modules/views/src/Tests/FieldApiDataTest.php:
Value 'Appears in: page, article. Also known as: Content: The giraffe" label' is equal to value 'Appears in: page, article. Also known as: Content: The giraffe2" label'.

fail: [Other] Line 106 of core/modules/views/src/Tests/FieldApiDataTest.php:
Value 'Appears in: page, article. Also known as: Content: The giraffe2" label (field_name_0)' is equal to value 'Appears in: page, article. Also known as: Content: The giraffe" label (field_name_0)'.

Views_ui.Drupal\views_ui\Tests\HandlerTest
✓		- setUp
✓		- drupalGet
✓		- testUICRUD
✗	
testHandlerHelpEscaping
fail: [Other] Line 173 of core/modules/views_ui/src/Tests/HandlerTest.php:
Escaped "Appears in: page, article. Also known as: Content: The giraffe" label alert("the return of the xss")" found
✓		- testBrokenHandlers
Branch result

.

Drupalci is running master still. I contacted infrastructure to move to 7.0 which should cut down on some.

Sorry for the late update to this, we moved to using the tip of the PHP-7.0 branch now (*not* the PHP-7.0.0 branch).

Re-opened #2581459: UpdatePostUpdateTest is extremely fragile to change and does not test batches in post updates which looks like it regressed on PHP7.

Needs issue:

iews_ui.Drupal\views_ui\Tests\HandlerTest
✓		- setUp
✓		- drupalGet
✓		- testUICRUD
✗	
testHandlerHelpEscaping
fail: [Other] Line 182 of core/modules/views_ui/src/Tests/HandlerTest.php:
Escaped "Appears in: page, article. Also known as: Content: The giraffe" label alert("the return of the xss")" found
✓		- testBrokenHandlers

Needs issue:

Views.Drupal\views\Tests\FieldApiDataTest
✓		- setUp
✗	
testViewsData
fail: [Other] Line 103 of core/modules/views/src/Tests/FieldApiDataTest.php:
Value 'Appears in: page, article. Also known as: Content: The giraffe" label' is equal to value 'Appears in: page, article. Also known as: Content: The giraffe2" label'.

fail: [Other] Line 106 of core/modules/views/src/Tests/FieldApiDataTest.php:
Value 'Appears in: page, article. Also known as: Content: The giraffe2" label (field_name_0)' is equal to val

Just found:

https://wiki.php.net/todo/php70#timetable

RC6 is October 29th

7.0.0 final is November 12th.

There are core release windows on the 5th and 18th of November, then the 2nd December (? on December date).

It is likely that November 5th is another release candidate, which means any incompatibilities between 8.0.0 and PHP7 not resolved by Nov 12th definitely aren't blocking a PHP7 stable and may block 8.0.0 (or require some kind of mitigation). Based on that, bumping to critical now.

Tagging

The core committers met and discussed this issue in relation to picking a D8 release date.

It looks like PHP 7 is due out on November 12, according to https://wiki.php.net/todo/php70#timetable. Since that's less than 3 weeks away, that will be before D8's minimum viable release date.

Decision was to keep this critical, but don't let it affect D8's release date, since everything that's left is segfaults, versus known problems in our code. If we can get it done in time (and we should definitely try), awesome; if we can't, "plan B" is to do #2576745: Add a hook_requirements() warning when running on PHP7 a few days ahead of release.

Adding that to the issue summary.

Organized a list of currently failing testbot tests: #2603152: Fix PHP 7 testbot failures

Based on the work done in #2603152: Fix PHP 7 testbot failures we have one patch for the gc hack to get us to one fail.

Then exactly one test that fails on PHP 7.

Between now and those getting into either the next PHP release candidate or 7.0.0, I think we could do the following to stop any regressions in core code:

- commit the gc patch.
- add a version check hack to the single failing test so it skips on PHP 7.

Then we'll have 100% on PHP branch tests, and regressions in either core code or PHP itself will be very obvious.

Then we have a critical issue to revert each change as soon as the commit is on DrupalCI (that may already be possible with the gc patch, or could be in a day or so).

Needs review on the idea.

The GC bug has a fix already committed to PHP 7, apparently: https://bugs.php.net/bug.php?id=70808 (Note: I've not tried it to see if it actually fixed the issue.)

Assuming that does, would we rather run PHP 7 master for a while on testbot, or apply the workaround patch until the next tagged release of PHP 7?

The remaining issue seems pretty far off the critical path, so I'd be comfortable just disabling it for now to make sure we have no other regressions. +1

We run the release branch with daily builds on DrupalCI afaik, however the PHP 7 commit is not in the release branch yet.

Switching to master risks instability compared to the release branch which might not help us stay green on it. Although we'll want to figure out which branch we test against once we're properly 100% green and 7.0.0 is actually out.

So for me I'd commit the workaround, then have issues with patches to remove it that we can send for re-test and do so as soon as it's green on DrupalCI.

@Crell that fix was not for the garbage collection issue (which is https://bugs.php.net/bug.php?id=70805)

Discussed #164 with alexpott and neclimdul, and have gone ahead with that plan.

I've sent HEAD for retesting (https://www.drupal.org/node/3060/qa).

So we should have a green test run on PHP 7.

Therefore, marking this issue postponed. Once fixes for either issue are in DrupalCI, we can post a revert patch somewhere, confirm the green test run, and then revert the commits from

Talking more with @alexpott, I've swapped out the PHP 7 release checklist item with this issue, so we don't forget to revert those commits if we can - #2559575: [meta] The Drupal 8.0.0 Release Checklist.

With that on the checklist, this can then be major/rc target since there's nothing actionable here, and we can release in the current state in the worst case those fixes didn't make it into 7.0.0.

Opened #2607222: [policy, no patch] Default to PHP 7 for Drupal core patch testing.

Quick update from upstream:

laruence, who is working from an EC2 instance I have setup for him with complete Drupal 8, gdb, etc., has found the bug - it indeed has been in the GC, but they still investigate some double free's that might or might not be related to that bug but do happen with our test suite.

TL;DR (from IRC): The GC tries to add a root (e.g. during __destruct of a class) for something that was tried to add a root for, but then triggered the GC as the max roots limit (10k) was reached. That then led to a double free.

Also of note for future us, to run gdb + php easiest use:

php7 ./core/scripts/run-tests.sh ... --php /usr/bin/php-gdb

and in php-gdb:

#!/bin/bash

exec gdb --args /usr/bin/php7 "$@"

Then a debugger can be used comfortably with the simpletest script.

And its fixed upstream! https://bugs.php.net/bug.php?id=70805

Now we just need to wait to which version the bug fixes get cherry-picked :).

It was actually committed to the 7.0 branch so we should see it in the next snapshot build.

Putting up patches for reverting the workarounds so we can run them against the bot. Presumably we don't have either yet, but worth a look.

I just got confirmation in IRC that both bug fixes will be in 7.0.0 stable, which means that when PHP 7.0.0 is released, Drupal 8 (and especially our test suite) will be supported without the temporary hacks! :)

Looks like the first one can already be reverted! :)

Reverted that.

The 2nd one now also passed and can be reverted! :)

Done!

Need to leave this open to track that the two commits actually make it into PHP 7.0.0 (or it'll be an 8.0.0 release notes/requirements mention).

Also need to do the same for the postgres PDO fail.

Moved closed child issues to fixed.

Added #2608558: PostgreSQL + PHP 7 test failures as child issue (latest bug: https://bugs.php.net/bug.php?id=70866)

Looks like PHP release has slipped :(

http://news.php.net/php.internals/89102

Also on https://wiki.php.net/todo/php70#timetable now.

Note that http://news.php.net/php.internals/89102 specifically mentions https://bugs.php.net/bug.php?id=70805 which is a bug we reported.

So while it's not great that it slipped, it's fantastic that we caught that issue before release rather than afterwards, and that we should have Drupal 8.0.0 and PHP 7.0.0 100% compatible (at least to the extent of our test suite).

If I understand correctly PHP7 RC7 will include both of the aforementioned bug fixes, therefore all tests will be passing in a stable release, and the 4th bullet point of "Problem/Motivation" no longer applies, so PHP7 will officially be classed as supported by D8.0.0 regardless of which actually releases first?

@MustangGB:

We've already removed both workarounds from core, so 8.0.0 + PHP 7 now has 100% pass with MySQL.

Regardless of what happens with PHP release cycle, I don't think we need to make any core changes beyond what we've already done.

#2608558: PostgreSQL + PHP 7 test failures is still open for PHP 7 + PostgreSQL failures - these are all likely PHP 7 bugs, and hopefully they'll be fixed by 7.0.0 - we may need a drupal.org/requirements mention and/or release notes mention if PHP 7 and postgres don't pass when 8.0.0 is released. I think that's the full extent of what we have to do though, as long as there's no regressions on either our end or theirs.

Reading that thread a bit more...

Had the release come out on Nov 12th, it would not have contained the segfault fixes merged last week - they would have been in 7.0.1.

Instead those will get into the next release candidate, so 7.0.0 ends up compatible with 8.0.0.

So the delay of PHP 7.0.0 is all Drupal's fault. Go team! :-)

RC7 is out: http://php.net/archive/2015.php#id2015-11-12-1

Added #2617568: Rename apc_* functions with apcu_* - which is needed for PHP7 apcu support. (and potentially PHP 5.5 too if apcu removes the BC layer of APC there as well).

Tagging 8.0.1 target, there may be a stable PHP7 release by then.

Everything is very broken on testbot ci and PHP7 atm

https://www.drupal.org/pift-ci-job/91034

Passed again today. I've seen quite a few CI aborted errors recently, also on patches on the default branch.

phpbuild and phpenv started enabling xdebug by default on php7, and since we use those tools to build daily, we inherited that configuration change. We've since disabled xdebug (yesterday), but pretty much any fails for the last five or so days can be attributed to xdebug rc2 not being ready for php7. Apologies that we were unaware this was happening until yesterday.

PHP 7 RC8 Just released http://php.net/archive/2015.php#id2015-11-26-1, and its docker image should be available shortly.

Hi guys, can anyone help me with this issue please? php7 incompatibility

If you wonder why your contrib module fails testing on PHP 7 check out #2616498: Drupal\Core\Routing\RouteProvider::getCandidateOutlines() does an illegal shift when config is empty, fixed the problem for Rules.

PHP 7 was just released:

https://news.ycombinator.com/item?id=10661997

PHP 7 was just released

Or, more accurately, they've just tagged a release in github as 7.0.0. The actual release itself is still targeted for tomorrow, 3rd December: https://wiki.php.net/todo/php70#timetable

I guess this means they're still on track, and don't expect any more RC to be necessary.

We could stil use an issue summary update as the current issue summary makes things seem more dire than they are...

Complete this quotation from 1966:

The fans are on the pitch. ... They think it's all over. ...

Or, to bring the conversation back to PHP 7:

PHP 7 was just released

Or, more accurately, they've just tagged a release in github as 7.0.0. The actual release itself is still targeted for tomorrow, 3rd December: https://wiki.php.net/todo/php70#timetable

I guess this means they're still on track, and don't expect any more RC to be necessary.

... It is now!

Have anyone manually tested D8 install on PHP 7.0.0? Feeling excited :)

Ondrej has updated his PPA so I just did a fresh D7 and D8 install to play/test with as well!

Berdir spotted this six months ago in #114, but there's still a weird cosmetic issue that only affects PHP 7: #2633628: Table columns are out of order in PHP 7

#2617568: Rename apc_* functions with apcu_* caused #2646100: Exception on php7 + APCu without backwards compatibilty enabled.

On PHP 5 backwards compatibility can be enabled with a configuration option, but PHP 7 requires a separate extension (see https://secure.php.net/manual/en/apcu.installation.php). I ran into the issue because OSX Homebrew doesn't have apcu_bc available yet.

This issue covers Drupal 7 also, so I'm updating the issue summary to reflect that.

In short: Look at #2656548: Fully support PHP 7.0 in Drupal 7 for some details regarding Drupal 7.

The Ubuntu folks are planning to get PHP 7 in the main repository for the next long-term support (LTS) release in April (16.04), but they need folks to help with testing; Drupal was listed specifically. Everything needs to be sorted by the February 18th, or it may not happen. See the announcement in the issue for more information.

@colan I missed your comment. If it's not to late I'd just point them to https://www.drupal.org/node/3060/qa which shows Drupal 8 passing on PHP7.

We have branch tests running on PHP7 now, and #2607222: [policy, no patch] Default to PHP 7 for Drupal core patch testing open to default to it, which is blocked on a DrupalCI issue. But I think this meta can be closed. Added issue credit for everyone with 4+ comments. This was a good issue.

This isn't fixed for Drupal 7 yet, but looks like it will be soon (and we have the separate issues for running tests and actually backporting the patches already). I guess we can be optimistic and leave it at "fixed" :)

Today Ubuntu 16.04 was released with PHP 7. Drupal 7 not being ready for PHP 7 was specifically mentioned: https://wiki.ubuntu.com/XenialXerus/ReleaseNotes

D7 issue is here: #2656548: Fully support PHP 7.0 in Drupal 7

Today Ubuntu 16.04 was released with PHP 7. Drupal 7 not being ready for PHP 7 was specifically mentioned

Odd, as far as I understand the issues are all minor. And Drupal 7 doesn't currently pass tests on PHP 5.4 or PHP 5.5 either but no one complained before :)

That said, hopefully we can get all the patches committed and tests fully passing for the upcoming release. Contrary to what I've seen posted on Twitter recently, those patches aren't all RTBC yet (some are, but several others have been "needs review" for months - see #2656548: Fully support PHP 7.0 in Drupal 7 for details). I'll probably review them myself if no one else does (and hopefully mark them RTBC), but I don't really like being the only reviewer and committer on the same patch, so it would be great to have others who are interested in PHP 7 support look at them also.

Uh, I didn't mean to change the version but the old one no longer exists I guess.

Odd, as far as I understand the issues are all minor. And Drupal 7 doesn't currently pass tests on PHP 5.4 or PHP 5.5 either but no one complained before :)

I'm quite sure that they're talking about the Drupal 7 Debian package "drupal", not Drupal 7 in general.

In https://wiki.ubuntu.com/XenialXerus/ReleaseNotes#PHP_7.0 it specifically says they held it back because the upstream (i.e. Drupal 7 core) tests aren't passing.

What I'm wondering is why something similar wasn't done before, e.g. when https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes introduced PHP 5.5. I suspect the answer is lack of visibility - probably no one know the PHP 5.5 tests weren't passing because there was no real way to see that on drupal.org at the time :)

Add support for session.uploadprogress since uploadprogress PECL extension doesn't compile for PHP 7 and the developers of it said they are considering deprecating it.

I spent several hours trying to integrate the PHP 5.4's native file upload progress support (in Drupal 7, but 8 should be similar). It works in a regular mod_php environment with no further modifications (upload progress is enabled by default in php.ini), but unfortunately it does not seem to work with custom session handlers.

It seems the ZF guys had the same issue, and could not figure out a fix. The upload progress data is somehow saved to file-based storage, but never to the abstract session we populate/write from the database. https://github.com/zendframework/zendframework/issues/4821 , http://php.net/manual/en/session.upload-progress.php#117188

https://github.com/Jan-E/uploadprogress compiles and runs absolutely fine: Clone the repository, configure, make, make install and add uploadprogress.so to your php.ini file(s)