Some of that looks like things HHVM (and the compile step involved) related to “generated code”. With dynamic classes being even more attractive with PHP7, we should not target HHVM anymore. The speed gain HHVM promised is delivered by PHP7 and we have that working by now.
I agree, tried HHVM out as well previously before PHP 7 was out. But since then the argument for HHVM has become weak, especially for something like Flow/Neos. So don’t really see much benefit in spending resources keeping it compatible with HHVM currently. Additionally nobody really requests or complains about it. So our efforts are properly better spend elsewhere.
Our last comparison of HHVM vs PHP7 back in october (PHP7-RC1) told us differently and we saw an up to 10x better performance (req/s) on HHVM over a PHP7 fcgi setup when running our Flow 3.0 registration application. We had no real problems apart from some Fluid issues with non-CDATA’d javascript (probably due to some differences in regex parsing).
So I’d not say HHVM is obsolete and can just be ignored, but it’s definitely not something that a lot of people will use as a Flow/Neos setup, let alone because setting up a PHP environment is just so much more straightforward. So saving resources here is ok.
Since we will probably keep working with HHVM a bit longer, maybe I can spend a few hours in getting tests back to running (sometime in january probably).