The fix for this should presumably also support Hack collection literals in Hack files (or with hhvm.force_hh enabled).
Fix is up internally D1688260
will it automatically close github bugs when internal fixes are landed?
Yes, usually.
Haven't had a chance to fix remaining test failures, but code is now here for the curious: https://reviews.facebook.net/D29163
define() now supports them in php-src master (it'll be in PHP 7.0), so whoever adds support for this in HHVM should make sure it works with define() too: https://github.com/php/php-src/commit/0833fd4619978c0522056b44dd53cd3b9d974cdd
@paulbiss what's the current status?
Did this get in?
I am pretty sure that this is still not supported :-((
There is an alternative to get around the problem that can be reversed when it is fixed?
No workaround is needed for defining with const, HHVM supports that now.
If you need define(), though, try this:
function defineWorkaroundForHHVM(string $name, $value) /* : void */ {
$slashPos = strpos($name, '\\');
$namespace = "";
if ($slashPos !== false) {
$namespace = substr($name, 0, $slashPos);
$name = substr($name, $slashPos + 1);
}
$value = var_export($value, true);
eval('namespace ' . $namespace . '{ const ' . $name . ' = ' . $value . '; }');
}
(You probably shouldn't use this code.)
Sorry @TazeTSchnitzel, I was not clear, is about arrays class constant values.
It does not work on PHP7 compatibility neither:
hhvm -d hhvm.php7.all=1 whatever.php
result: Arrays are not allowed in class constants
Doesn't work for me in latest either
Been a few months, this deserves a bump. I would like to use arrays in class constants, too!
I wonder, why this, absolutely harmful in its absence, feature is still not supported by hhvm after 3 years?
A brief inspection of code indicates, that prohibition of const arrays (either global scope or in-class) even managed to survive the recent refactoring of datatype/variant handling, so it probably was a deliberate decision by the implementors.
However, nowadays massive amounts of php code depend on const arrays and their use is increasing, thus making migration to hhvm outright impossible, despite all the other advantages hhvm may have provided.
Almost all my new PHP code uses constant arrays somewhere, and therefore probably won't work on HHVM. I doubt I'm alone here, it's a very useful feature.
I have to refactor all our codebase to remove all const array to try hhvm and after that I realize it is impossible to use latest hhvm on anything else than ubuntu and debian, so this is a bye bye to HHVM OTOH php 7 is even faster in my tests so no harm here :)
@mofarrell @paulbiss bump
Added 'probably easy' given I guess a lot of the required work was already done to support https://github.com/facebook/hhvm/blob/master/hphp/test/quick/vec/static.php
@fredemmott
To my humble understanding fixing this would require a new class derived from Array (something like "StaticArray" with appropriate bounds on values). There's no indication in current code (3.17 that is) that anything was done in this direction.
IIRC that's existed for a long time (used by array literals and APC) - but the plumbing to hook them up to classes didn't exist.
HHVM is a nice tech, especially when it's native api is concerned, but this feature here is a huge blocker. On behalf of the wider user community I urge you to take a look at fixing this. :-)
Re: https://github.com/facebook/hhvm/issues/4277#issuecomment-66213113
It seems like reviews.facebook.net is no longer a public site (or just the review https://reviews.facebook.net/D29163).
Is it possible to commit the original commits for that PR and link to it (Or just post a patch file of the diff for that commit) in this issue?
There is work ongoing internally to fix this as part of supporting hack arrays properly.
reviews.facebook.net no longer exists in any form - it's not just no longer public.
@ricklavoie

Is this only for PHP? Hack code still gives the same error.
````
class Foo {
const array
}
````
Tested using 3.19.1
hhvm: Catchable fatal error: Hack type error: Illegal constant value at ...
hh_client: Illegal constant value (Naming[2023])
HHVM supports it, the typechecker doesn't.
@wulftone : typechecker now supports it
Most helpful comment
HHVM is a nice tech, especially when it's native api is concerned, but this feature here is a huge blocker. On behalf of the wider user community I urge you to take a look at fixing this. :-)