Practically, the second WMF finishes its switch back to Zend HHVM support will crash and burn, so my own feeling is that we should aim towards removing HHVM specific hacks and adding a warning in installer that whomever using it is doing so at their own peril.

In T192166#4130427, @MaxSem wrote:

Practically, the second WMF finishes its switch back to Zend HHVM support will crash and burn, so my own feeling is that we should aim towards removing HHVM specific hacks and adding a warning in installer that whomever using it is doing so at their own peril.

Yeah, I imagine this will happen with MW 1.32, but we'll see.

In T192166#4130427, @MaxSem wrote:

Practically, the second WMF finishes its switch back to Zend HHVM support will crash and burn, so my own feeling is that we should aim towards removing HHVM specific hacks and adding a warning in installer that whomever using it is doing so at their own peril.

I don't disagree with you about removing the hacks, but HHVM will probably remain (mostly) usable until we also kill the CI jobs that use HHVM to run the tests.

We'll probably have to keep those jobs running for 1.31 backports until support for that LTS version expires, although we might stop running those jobs against later branches as soon as WMF no longer uses HHVM in production.

Yeah, but do we want to waste our time and hardware resources on running HHVM tests on master then? :)

Change 426165 had a related patch set uploaded (by MaxSem; owner: MaxSem):
[mediawiki/core@master] WIP: kill HHVM specific hacks

https://gerrit.wikimedia.org/r/426165

As I said, "although we might stop running those jobs against later branches as soon as WMF no longer uses HHVM in production."

Change 434973 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] [DNM][WIP][GOSH] Drop HHVM support from MediaWiki

https://gerrit.wikimedia.org/r/434973

So I tried using variadic parameters in OutputPage, and got this when mocking the class:

Fatal error: Parameter $args is variadic and has a type constraint (array); variadic params with type constraints are not supported in non-Hack files in /workspace/src/vendor/phpunit/phpunit-mock-objects/src/Framework/MockObject/Generator.php(290)(683e42bc664577e05b3456a65ea29c3b) : eval()'d code on line 3297

Apparently due to this: https://github.com/facebook/hhvm/issues/6954 Open since March 2016, and it seems to mean you can't mock classes with variadic parameters in their methods, or something like that. I'm not sure what the exact issue is, but the variadic arguments I added to OutputPage methods had no type declarations, and I still got the error. This is the second issue I've run into in the last two weeks where HipHop didn't support a PHP 7 feature I wanted to use. (I can't remember the first.)

Another one:

"Fatal error: Arrays are not allowed in class constants"
https://integration.wikimedia.org/ci/job/wmf-quibble-core-vendor-mysql-hhvm-docker/68/console

https://github.com/facebook/hhvm/issues/4277

Seems it's been supported in actual PHP since 5.6.

Another HHVM-only error, seemingly:

https://gerrit.wikimedia.org/r/451636
https://integration.wikimedia.org/ci/job/wmf-quibble-core-vendor-mysql-hhvm-docker/385/console

I don't know what the root cause of this one is, it seems something isn't an array that should be.

@MaxSem @Jdforrester-WMF Why are there currently two patches to drop MediaWiki HHVM support? Looks like you are trying to do the same thing (with similar results). Shouldn't you merge these efforts?

I've cleared these big standalone tasks from the tree (in favour of mention in task description) so that we can use this task directly as sub task or parent task of other tasks part of the HHVM-dropping effort. E.g. tasks blocked on dropping HHVM support first, and sub tasks to be done as part of the process to remove support.

In T192166#4540912, @MGChecker wrote:

@MaxSem @Jdforrester-WMF Why are there currently two patches to drop MediaWiki HHVM support? Looks like you are trying to do the same thing (with similar results). Shouldn't you merge these efforts?

Mine goes a bit further but I haven't carefully gone through Max's patch to ensure I've caught every item he did yet. When dropping HHVM is closer I'll take a proper look.

While we'll have to drop HHVM support soon, we're migrating to PHP 7 even sooner. So this isn't currently blocking PHP 7.0 support.

Per T176370, the initial production roll-out will likely use PHP 7.2, or maybe PHP 7.3 even (we're currently evaluating the viability of fast-tracking that and do the gradual roll-out straight from HHVM to PHP 7.3 for user traffic). More details and question at T176370, but it does mean we won't drop HHVM until after PHP 7.3 support is finalised.