Hhvm: HHVM php 7 mode not recognized by composer as PHP 7

[photodude]

HHVM Version 3.17.1

Standalone code, or another way to reproduce the problem

when a composer package specifies php ^7.0 HHVM gets rejected even if PHP 7 mode is turned on.

in composer.json

"require": {
        "php": "^7.0"
}

Expected result

HHVM in PHP 7 mode should supply composer with version information that tells composer HHVM is valid as php ^7.0

Actual result

This package requires php ^7.0 but your HHVM version does not satisfy that requirement

Additional Comments

Note: Composer is also Broken when HHVM is in PHP 7 mode due to issue #7198

[mofarrell]

I believe #7198 is an issue, but I cannot repro this.
With the following composer.json:

{
  "require": {
    "php": "^7.0"
  }
}

Running:
hhvm -d hhvm.php7.builtins=1 ../composer.phar require succeeds.
While running:
hhvm ../composer.phar require fails with:

  Problem 1
    - This package requires php ^7.0 but your HHVM version does not satisfy that requirement.

It is worth noting that running:
hhvm -d hhvm.php7.all=true ../composer.phar require fails because of #7198

[photodude]

Yes our failure is with hhvm.php7.all=true but its separate from the rtrim() issue in https://github.com/facebook/hhvm/issues/7198

As the failure here is

Problem 1
    - This package requires php ^7.0 but your HHVM version does not satisfy that requirement.

[photodude]

@mofarrell here is a link to a full composer that has this issue
https://github.com/php-api-clients/psr7-oauth1/blob/master/composer.json

note: running HHVM with hhvm.php7.all=1 and it errors with package requires php ^7.0 without hitting the issue in #7198 where rtrim() expects parameter 1 to be string, null given

[mofarrell]

Do you hit this with -d hhvm.php7.builtins=1? What version of composer are you using?

Creating a small example where phpversion() does not return the correct version would be helpful.

[photodude]

composer version 1.3.2

I'm going to close as I'm no longer able to replicate as of HHVM 3.18.1

Now I'm stuck with just the issues in #7198

[ilemonajames]

Has anyone found solutions to this issue? Am stuck on this

[fredemmott]

If you're using HHVM 4.0 or above, use real PHP to execute composer, not hhvm.

[photodude]

@ilemonajames HHVM no longer has any goal of fixing all of the PHP7 issues, or targeting any specific version of PHP. HHVM/HACK has split from PHP and is doing their own thing. Basically, all PHP projects have dropped all efforts related to HHVM compatibility (I have also dropped my efforts). Most of the early HHVM benefits of better typing and speed are found in PHP 7.2+

For more info on Why HHVM is changed see this old announcement https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html

I also recommend watching this talk from the creator of PHP on the future of PHP and changes PHP 7 has made
https://youtu.be/rKXFgWP-2xQ

[fredemmott]

Basically, all PHP projects have dropped all efforts related to HHVM compatibility (I have also dropped my efforts).

Hack and PHP are definitely best considered separate languages nowadays; there are common functions (especially involving byref arguments) that are literally impossible to call in way that both PHP7 and HHVM 4 are happy with.

[Manishfoodtechs]

I solved this by following step:

1. Run Php -v .
2. Assuming you are on windows and having wamp server ; you need to edit environment system variable --> Path of required php version. I used this for myself: C:\wamp64\bin\php\php7.3.2
   3.Restart.
3. update composer by creating composer.json as given in https://getcomposer.org/doc/01-basic-usage.md#composer-json-project-setup
4. Now error will go away.

[photodude]

@Manishfoodtechs That is a workaround and does not actually address the issue here. This was specifically about HHVM running Composer. This is not about sideloading PHP just to make composer work or to remove an error. (it's a great workaround for someone in 2015-2017 when HHVM compatibility was a thing to try for in the PHP community... but not really a thing now)

It's really a mute point as HHVM is own thing and is now considered a wholly separate language from PHP. There is no longer a point in trying to cludge PHP projects to make them run on HHVM. PHP 7.2+ has realized many of the reasons for HHVM hence one of many reasons why HHVM split.

All notable PHP projects have dropped any and all efforts related to HHVM compatibility (I have also dropped my efforts).

[fredemmott]

In particular, no code that calls functions with byref arguments can be written in one way that runs under both PHP and HHVM; this removes compatibility with the vast majority of PHP tools and libraries, including composer itself.

For example:

$values = [4, 1 ,2];
sort($values); // valid in PHP, but not HHVM
sort(&$values); // valid in HHVM, not PHP

HHVM 3.30 was the last release with any practical level of support for PHP, and will reach end of life in ~ 2 months.