More specifically, any PHPUnit mock/stub encountered by tests throws an error like:
1) ActorMigrationTest::testInsertRoundTrip with data set "normal" ('actormigration1', 'am1_user', 'am1_id', false) ParseError: syntax error, unexpected token "match" /Users/mateszabo/Wikia/mwdev/mediawiki/tests/phpunit/includes/ActorMigrationTest.php:545 /Users/mateszabo/Wikia/mwdev/mediawiki/tests/phpunit/MediaWikiIntegrationTestCase.php:437 /Users/mateszabo/Wikia/mwdev/mediawiki/maintenance/doMaintenance.php:106
on PHP 8 + MW master.
unexpected token "match"
Yea, see http://maettig.com/2020-09-21-prepare-for-php-8. Functions named match might be one of the bigger PHP 7→8 problems we have. I started renaming some already. Here is the rest: https://codesearch.wmcloud.org/search/?q=function%20match%5Cb&files=%5C.php%24. This doesn't cover Wikia codebases, unfortunately.
Yup, the problem is that the problematic code is within the mock code autogenerated by PHPUnit, so I don't see how it can be avoided without going through the hassle of upgrading PHPUnit (v9 brings another slew of breaking changes)
PHPUnit 9 is compatible with PHP8, but dropped PHP7.2 and older.
It looks like WordPress will be using PHPUnit 7 (or 8?) with patches for PHP8, rather than the approach we took in the past where we used multiple PHPUnit versions side-by-side with local traits to emulate the newer version on the old version.
I still want to pro-actively want to backport them as we're making them; if they don't cause breaking changes etc (and obviously work on PHP 7). Means we don't have to find them later, or re-make them etc
Master and REL1_35 (ie the branch, not 1.35.0) of MW core will be similar
I don't know if it's well tested, but it does seem "test" related code is probably more problematic than normal workflow.
Testing appreciated. Feel free to report bugs or submit changesets to fix issues
Exactly. Very "fun". That is my feedback so far: don't pin monolog and other dependencies, especially to something that cannot be installed with the latest PHP version. Or, at the very least, switch the pin to any more recent version than monolog 2.0.2, which all allow installation with PHP 8.
Doesn’t help when we have code in core that depends on classes in a 3rd party library, and we can’t easily support both versions when signatures change... so no point in letting you install it if it won’t work if you try to use it....
Given that we've found everyone on Earth disagrees as to the exact semantics of SemVer in ways that have broken master and threatened the stability of production, including composer themselves, no.
Or, at the very least, switch the pin to any more recent version than monolog 2.0.2, which all allow installation with PHP 8.
Yes, that's the plan. :-) Unfortunately their support expanse comes at the expense of breaking changes that they don't consider breaking in their output, so we have to re-validate all the security logging etc. again.
Squashed a patch set together, which now passed for the composer job on master: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/662089
That means: Closing the sub tasks should make it work for mediawiki/core as other failing tests are now passed
elasticsearch/elasticsearch needs update to also work on the vendor job (T271777)