We have decided to skip this week’s regular release, HHVM 4.63.There have been some bugs that prevented us from publishing the release earlier
this week. Instead of shipping the release only a few days before the next one,
we decided to skip it.Support for HHVM 4.57 will be extended until the release of HHVM 4.64, scheduled
for next week.Breaking ChangesWe expect next week’s HHVM 4.64 to contain some significant changes affecting
legacy (PHP-style) arrays. We expect array(...) literals to be completely removed in the next release.
All code will need to be migrated to varray[...] and darray[...], or
preferably vec[...] and dict[...] (if it can be done safely).
Automated migration is available in HHAST
v4.33.6 or newer: hhast-migrate --php-arrays
The INI flag hhvm.hack_arr_compat_specialization will be removed and its
behavior will be enabled by default. We highly recommend enabling this flag in
your current HHVM release before upgrading to HHVM 4.64.
This change disables the implicit inter-operability between varrays and
darrays. Instead, varray and darray will be treated
as types in their own right. Specifically:
Using a varray where a darray is expected (at parameter and return value
typehints) will throw, and vice versa. The same goes for property typehints,
if they are checked at runtime.
varrays will now maintain a “vec-like” layout, with integer keys from 0 to
(size - 1). Attempting to set a string key in a varray will throw, as will
attempting to unset any element other than the last one.
Tuples and shapes are internally represented as varrays and darrays,
respectively. As a
result, darray is tuple(...) will return false and darray as tuple(...)
will throw. The same goes for varray is shape(...) and
varray as shape(...).
Comparing a varray and a darray using == or === will always return
Attempting to compare varrays to darrays relationally with = will result in an exception.
HHVM (HipHop Virtual Machine)会将PHP代码转换成高级别的字节码（通常称为中间语言）。然后在运行时通过即时（JIT）编译器将这些字节码转换为x64的机器码