HHVM and PHP7 differ on type annotations on internal functions (rtrim in particular)

[apeabody]

What is the expected behavior with regards to strict type checking? PHP7 defaults to “coercive mode” while hhvm.php7.all = 1 appears to act like "strict mode" in this example?

HHVM Version

HHVM 3.14.1 hhvm.php7.all = 1 PHP 7.0.4

Standalone code, or other way to reproduce the problem

<?php

$result = rtrim(null);
echo $result;

Expected result

identical (no output)

Actual result

hhvm --php test.php

Warning: rtrim() expects parameter 1 to be string, null given in /home/vagrant/hhvm/hphp/test.php on line 3

php7 test.php

Potential Solutions

Perhaps hhvm.php7.scalar_types should be left out of hhvm.php7.all? It appears currently to make HHVM act like PHP7's declare(strict_types=1); mode.

[fredemmott]

This is probably too intrusive a change for LTS backporting: it's much more important that 3.x.y can run code that 3.x.(y-1) could than for 3.x.y to be able to run /more/ code, even if the code running on 3.x.(y-1) was 'wrong' in some way. Exceptions are rare, except for security fixes.

[robfrawley]

The was a insurmountable language bug that caused a divergence between HHVM's internal function type handling from that of PHP's; it should be back-ported IMHO.

If it isn't back-ported to the latest LTS it won't be natively available on any distribution until their next LTS release, which will cause more project to abandon HHVM. It's an important fix that would ease concern from the PHP community and hopefully allow you to win back some support. Again, it should be back-ported.

[Orvid]

@fredemmott My understanding is that we do have plans to backport it to at least the current LTS.

[fredemmott]

If you're reasonably confident that this won't break existing code written to run on HHVM, I don't mind this being backported.

Regardless of the type of bug, unless there's a security issue that makes code changes required, upgrading from 3.x.y to 3.x.(y+1) should never break code that is already running. If it does, that breaks the entire purpose of having LTS releases (and to a lesser extent, .y releases in general).

[simonwelsh]

If this does end up in 3.18, can you also make sure it ends up in 3.19/3.20? It'd be rather strange to have things work in 3.18 but not 3.19, and will make version constraints that much more annoying.

[fredemmott]

The general problem was fixed, but composer isn't; repro case for that issue: https://3v4l.org/ahpE3 (based on @photodude's comment above)

[fredemmott]

Filed #7869 for composer as the original issue here is fixed; working on the splfileinfo issue, and whatever else comes up when testing composer.

[photodude]

Also broken if null is passed to splfileinfo() resulting in the same rtrim() issue originally reported (since splfileinfo() is dependent on rtrim() as noted above ). https://3v4l.org/4ljZ8

[fredemmott]

yeah, we differ on any non-string input to splfileinfo

[hopeseekr]

This issue is needed, because *WE ARE NOT IN A PHP5 WORLD ANY LONGER.

The HHVM team, and Facebook Corp., need to be galvanized to committing to stay compatible with PHP7 or they need to break all pretenses and start marking Hack Language as its own thing.

Otherwise, once all PHP5 code is collecting dust, relatively soon, all of your, my, and their HHVM efforts will have been in vain!

Hopefully this PR is a wakeup call!

[photodude]

@hopeseekr PHP 5.6 is EOL the same month as PHP 7.0 at the end of 2018. I agree primary efforts should be on compatibility issues with PHP 7.1 and with the alpha/beta release of PHP 7.2.

the majority of new development in PHP land has moved to just PHP 7+ support, I agree HHVM needs to make more effort to do the same.