We are skipping the 4.173 release this week, and are revisiting our release process. We expect to share an update in the coming weeks.

HHVM 4.172 is released! 4.169 - 4.171 remain supported, as do the 4.168 and 4.153 LTS releases.

Highlights

• Fixed a bug preventing classes using a trait with require class <that class> from being mocked. (commit)
• Regular expression functions now have a new error type, for when regular expressions jitted by PCRE run out of scratch space: PREG_JIT_STACKLIMIT_ERROR These would previously be reported as generic internal errors, which made debugging tricky. (commit)

Breaking Changes

• Two compiler options have been renamed - when compiling a repo the compiler will no longer accept --module or --cmodule options as of this release. Please use their new names --dir and --cdir instead (new names added in release 4.169). This change is intended to avoid confusion wht the ‘modules’ experimental feature. (commit)
• The typechecker now disallows overriding an async method with a non-async one. This was previously allowed as long as the types in the signature were compatible, but this made it easy to accidentally write subtle bugs by leaving off the async keyword on the overriding method. (commit)
• When using the ‘modules’ experimental feature, note that the default value of the Eval.EnforceModules runtime option is changing from 1 (warn) to 2 (throw exceptions). (commit)
• When using the like_type_hints experimental feature, note that this release changes how these types (the union of dynamic and another type; e.g. ~int for the union of dynamic and int) are enforced in argument and return type positions. Previously they were enfoced the same as the dynamic type (i.e. any value would be accepted) but after this release they are enforced as the other type in the union would be (e.g. for ~int only integer values will now be accepted). (commit) See also (commit) for related changes adding new ways to write aspirational, un-enforced types via helpers in the HH\FIXME namespace.

HHVM 4.153.3, 4.167.1, 4.168.1, 4.169.1, 4.170.1 and 4.171.0 are released! 4.167.1 is the last release in 4.167 branch, while 4.168 - 4.170 remain supported, as does the 4.153 LTS release.

Note that HHVM 4.153.2 is also released accidentally, but it does not include any meaningful change since 4.153.1.

These releases fixes an issue introduced in 4.153.0 (commit). When combining with another commit introduced in 4.168.0, it leads to a segmentation fault when building a bytecode repository for repo-authoritative mode in gcc built HHVM. Earlier releases are not affected.

Highlights

• HHVM 4.171.0 includes the fix for repo mode, which is also back-ported to all supported HHVM versions (issue, commit). The fix makes it possible to migrate the command line flag for building a bytecode repository to --inputs from --ffile, which was dropped in HHVM 4.167.
• The following features are now considered preview features with an ongoing release, i.e. allowed by the runtime, but not the typechecker:
  • Diamond traits (docs, commit)
  • Modules (commit)
• Added ReflectionClass::getModule() (commit).
• Added ReflectionModule::getDocComment() (commit).
• Added HH\classname_from_string_unsafe to convert a string into a lazy class (commit).
• HH\embed_type_decl now supports repo mode (commit).

Breaking Changes

• The thrift extension now requires clearTerseFields functions in generated code (commit). Regenerating Hack files from the thrift definition with the latest thrift compiler would provide the required clearTerseFields functions.
• The following hh_server flags are renamed:
  • --enable-global-write-check-functions is renamed to --enable-global-access-check-functions (commit);
  • --enable-global-write-check is renamed to --enable-global-access-check-files (commit).

HHVM 4.170 is released! 4.167 - 4.169 remain supported, as does the 4.168 and 4.153 LTS releases.

Highlights

• The typechecker now rejects calls to type_structure with an invalid type as the first argument (e.g. type_structure(MyCoolType::class, 'TUhOh') when type MyCoolType = shape(...) Previously this was not flagged by the typechecker but would fatal at runtime. (commit)
• The lint for using UNSAFE_CAST with too broad an input type now suggests an autofix. (commit)

Breaking Changes

• The Eval.EmitClassPointers runtime option has been removed. The previous default behavior (option value 2; Foo::class expressions emit ‘lazy’ class pointers) is now the only supported behavior. (commit)
• Removed support for referring to config values using a wildcard (e.g. foo*bar = value or *foobar* = value in HDF configs. Adding values to a vector-typed config node such as MyVectorConfig.* = value remains supported. (commit)
• Remove support for hdf.loadpaths to specify paths to search when including other HDF configs. (commit)

A Note Regarding This Release

We are still working on a fix for https://github.com/facebook/hhvm/issues/9236 (inability to compile a repo in gcc builds of hhvm since release 4.168). If you rely on this functionality consider skipping this release or using nix packages built with clang. We will release updated versions of all supported releases once the fix is available.

HHVM 4.169 is released! 4.166 - 4.168 remain supported, as does the 4.153 LTS releases.

Highlights

• hackfmt now only allows up to 1 consecutive blank lines (previously 2).
• The compiler options --module and --cmodule are being renamed to --dir and --cdir to avoid confusion with the experimental ‘modules’ feature. (This item was retroactively added to this announcement on 2022.11.02).

Breaking Changes

• The $callback passed to fb_setprofile now receives all parameters, including non-default and default parameters. Previously only non-default parameters are passed to $callback.

HHVM 4.168 (LTS) is released! This release has long term support, so:

• this release will be supported for approximately 48 weeks
• the next LTS will be released in approximately 24 weeks
• HHVM 4.153 (LTS) and HHVM 4.165–167 remain supported
• support has ended for 4.128 (LTS) and 4.164

Status of Ubuntu 22.04 support

We had intended for this release to have Ubuntu 22.04 support, but we are releasing without that support for now. Due to library version compatibility issues, we need more time to get this support working, and we did not want to delay the release for other platforms. We intend to make a 4.168.1 release with 22.04 support as soon as we get builds working on 22.04.

Note that our experimental universal packages (also available for version 4.168) are not affected by this issue and should be usable on any version of Ubuntu.

Highlights

• Fix a typechecker bug where enums that recursively include themselves were not being correctly rejected. (commit)
• Fix a bug where a lint could spuriously report a variable was shadowed when that variable was not actually shadowed due to the potentially shadowing write happening in the body of a lambda. (commit)
• Ignore case and don’t consider the class name when looking for ‘did you mean’ suggestions for invalid enum class labels. (commit1) (commit2)
• Improve printing of unresolved types in typechecker errors; e.g. Expected Awaitable<[unresolved]> But got int becomes Expected Awaitable<_> But got int (commit)
• Improve error message when accessing a shape with a value that’s not a literal or class constant. (commit)
• Improve error message from linter that points out when all return statements in a function return the same value. (commit) Also make this linter stop firing on functions that could plausibly be returning unix exit codes. (commit)

We’re happy to announce the availability of universal deb packages of HHVM, which do not depend on system libraries and are expected to run on any version of Debian, Ubuntu or any other Linux distributions with apt package manager.

The universal deb packages is still considered experimental like nix packages. We encourage you to try it out and report any issues you encountered. We will appreciate your feedback because it will help us decide if we will entirely switch from distribution-specific packaging to universal packaging.

Installation

These instructions require root; use su - or sudo -i to get a root shell first.

Obtaining The Latest Stable Version

1
2
3
4
5
6
7
apt-get update &&
apt-get install --yes software-properties-common apt-transport-https &&
apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xB4112585D386EB94 &&
add-apt-repository 'deb https://dl.hhvm.com/universal release main' &&
apt-get update &&
apt-get install --yes hhvm &&
hhvm --version

Obtaining A Specific Release Branch

1
2
3
4
5
6
7
apt-get update &&
apt-get install --yes software-properties-common apt-transport-https &&
apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xB4112585D386EB94 &&
add-apt-repository 'deb https://dl.hhvm.com/universal release-4.167 main' &&
apt-get update &&
apt-get install --yes hhvm &&
hhvm --version

Currently 4.167 is the only release version including universal deb packages. For future releases, you will be able to specify the apt suite name as release-x.yyy, where x is the major version and yyy is the minor version.

Obtaining The Nightly Version

1
2
3
4
5
6
7
apt-get update &&
apt-get install --yes software-properties-common apt-transport-https &&
apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xB4112585D386EB94 &&
add-apt-repository 'deb https://dl.hhvm.com/universal nightly main' &&
apt-get update &&
apt-get install --yes hhvm &&
hhvm --version

Known Issue

Note that the universal deb packages are built with nix package manager and then get repacked into deb format. As a result, the universal deb packages will conflict with packages directly installed from the nix package manager. If you are a nix package manager user, you should directly use the nix packages announced in this post, instead of the universal deb packages in case of path conflicts.

HHVM 4.167 is released! 4.164 - 4.166 remain supported, as do the 4.128 and 4.153 LTS releases.

Highlights

• Hover information has improved for constants, type names and enum classes.
• More of the built-in extensions (ext_json, ext_folly_variant, ext_thrift, ext_zlib, ext_server, ext_enum) have more extensive typing in their .hhi files, so the type checker can check code using them.
• .hackpartial settings in .hhconfig have been removed, specifically allowed_fixme_codes_partial, codes_not_raised_partial and strict_codes.
• hh_client now supports a --is-subtype to see if types are compatible, using JSON from --type-at-pos (commit).
• HHVM now supports overriding type constants on interfaces, even if they’re not abstract (commit).

Breaking Changes

• Having both <<__Memoize>> and <<__MemoizeLSB>> on a method is now a type error.
• The following flags has been removed from hhvm command.
  • --ffile
  • --target
  • -t

HHVM 4.166 is released! 4.163 - 4.165 remain supported, as do the 4.128 and 4.153 LTS releases.

Dropping support for Ubuntu 21.04 and 21.10

This release does not compile on Ubuntu 21.04 and 21.10. Both versions have reached End of Life earlier this year according to this post and this post. We are aware that we have not provided deb packages for Ubuntu 22.04 LTS. For now, Ubuntu 22.04 users could try our experimental HHVM binary built with Nix, which should be able to run on any Linux distribution.

Highlights

• Added support for upcasts in initializer expressions, e.g. class C { public dynamic $d = 3 upcast dynamic; }
• Added support for typechecking quote flag %'(char) in sprintf.
• Added support for <<__Docs("http://example.com")>> to type, newtype, enums and enum classes, which shows the docs URL in the IDE’s hover information
• Added a quickfix for Lint 5643 (Comparing booleans with values)

Breaking Changes

• Memoized functions with any of the following attributes now require the defaults capability:
  • <<__Memoize(#SoftMakeICInaccessible)>>
  • <<__Memoize(#MakeICInaccessible)>>
  • <<__PolicyShardedMemoize>>
  • <<__PolicyShardedMemoizeLSB>>
• Make null default parameter with non-nullable type hint result in error
• Always error on nested Expression Trees
• Lambdas and calls in Expression Trees are now virtualized:
  • Lambdas are now wrapped in lambdaType(...).
  • Calls are now translated to __unwrap() method instead of direct invoking.

HHVM 4.165 is released! 4.162 - 4.164 remain supported, as do the 4.128 and 4.153 LTS releases.

Dropping support for Ubuntu 18.04

This release does not compile on Ubuntu 18.04. Ubuntu 18.04 is outside our support lifecycle and this is the first HHVM version that depends on newer C++ features.

Highlights

• hh now computes smaller fanouts in some circumstances (such as enum constraints), making incremental typecheckers faster.
• Added Curl constants for libcurl 7.66 (commit).
• Major parts of systemlib now have explicit type signatures (e.g. ext_datetime), allowing the typechecker to catch more issues.
• Added lints for unconditional recursion and all function branches returning the same value.

We’re happy to announce that the Nix packages of HHVM are now available, as is the public CI status on GitHub Actions for it, and the Visual Studio Code workspace with HHVM dependencies from Nix. The Nix packages can be run on macOS and Linux of any distributions.

Currently, HHVM’s Nix packages are not officially supported, yet. They are provided as is and haven’t been extensively battle-tested. Since we have dropped macOS Homebrew support, it is likely that we will also stop building HHVM with Nix on macOS in the future, too.

How to Install HHVM Built With Nix

For NixOS Users

For NixOS users, add the following settings to /etc/nixos/configuration.nix to configure the binary cache for HHVM:

1
2
3
4
5
6
7
  nix.settings.substituters = [ "s3://hhvm-nix-cache?region=us-west-2&endpoint=hhvm-nix-cache.s3-accelerate.amazonaws.com" ];
  nix.settings.trusted-substituters = [ "s3://hhvm-nix-cache?region=us-west-2&endpoint=hhvm-nix-cache.s3-accelerate.amazonaws.com" ];
  nix.settings.trusted-public-keys = [ "hhvm-nix-cache-1:MvKxscw16fAq6835oG8sbRgTGITb+1xGfYNhs+ee4yo=" ];
  nix.settings.experimental-features = [ "nix-command" "flakes" ];
  environment.systemPackages = [
    pkgs.git # Required to support git+https protocol
  ];

In addition, if you want to build HHVM from source, add the following setting to disable sandboxing because HHVM cannot be built in Nix’s sandboxing build environment.

1
  nix.settings.sandbox = false;

Then execute the following shell command to apply the configuration to the system:

1
nixos-rebuild switch

Then add HHVM to system packages,

1
2
3
4
  environment.systemPackages = [
    (builtins.getFlake "git+https://github.com/facebook/hhvm.git?submodules=1&shallow=1&ref=refs/tags/nightly-2022.07.08").packages.x86_64-linux.default
    pkgs.git
  ];

and apply the configuration, again:

1
nixos-rebuild switch

Now hhvm is available.

1
hhvm --version

1
2
3
HipHop VM 4.164.0-dev (rel) (non-lowptr)
Compiler: 1657256394_118415120
Repo schema: 9845ff37f3bb751abbb48e4c823aa5641d5cb453

The above configuration has been tested on NixOS unstable and 22.11. The configuration for older NixOS might be different.

For Linux Users Other Than NixOS

For Linux users other than NixOS, the HHVM Nix package can be installed with the following command if you have a multi-user installation of Nix:

1
2
3
4
5
6
7
8
9
10
11
12
(
sudo tee -a /etc/nix/nix.conf <<EOF
extra-experimental-features = nix-command flakes
extra-substituters = s3://hhvm-nix-cache?region=us-west-2&endpoint=hhvm-nix-cache.s3-accelerate.amazonaws.com
extra-trusted-substituters = s3://hhvm-nix-cache?region=us-west-2&endpoint=hhvm-nix-cache.s3-accelerate.amazonaws.com
extra-trusted-public-keys = hhvm-nix-cache-1:MvKxscw16fAq6835oG8sbRgTGITb+1xGfYNhs+ee4yo=
sandbox = false
EOF
) &&
sudo systemctl restart nix-daemon &&
nix profile install 'git+https://github.com/facebook/hhvm.git?submodules=1&shallow=1&ref=refs/tags/nightly-2022.07.08' &&
hhvm --version

Or if you have a single-user installation of Nix:

1
2
3
4
5
6
7
8
9
10
11
(
cat >> ~/.config/nix/nix.conf <<EOF
extra-experimental-features = nix-command flakes
extra-substituters = s3://hhvm-nix-cache?region=us-west-2&endpoint=hhvm-nix-cache.s3-accelerate.amazonaws.com
extra-trusted-substituters = s3://hhvm-nix-cache?region=us-west-2&endpoint=hhvm-nix-cache.s3-accelerate.amazonaws.com
extra-trusted-public-keys = hhvm-nix-cache-1:MvKxscw16fAq6835oG8sbRgTGITb+1xGfYNhs+ee4yo=
sandbox = false
EOF
) &&
nix profile install 'git+https://github.com/facebook/hhvm.git?submodules=1&shallow=1&ref=refs/tags/nightly-2022.07.08' &&
hhvm --version

The above configuration is tested on Nix 2.9.1. The configuration for older Nix might be different.

For macOS Users

For macOS users, the HHVM Nix package can be installed with the following command if you have a multi-user installation of Nix:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
(
sudo tee -a /etc/nix/nix.conf <<EOF
extra-experimental-features = nix-command flakes
extra-substituters = s3://hhvm-nix-cache?region=us-west-2&endpoint=hhvm-nix-cache.s3-accelerate.amazonaws.com
extra-trusted-substituters = s3://hhvm-nix-cache?region=us-west-2&endpoint=hhvm-nix-cache.s3-accelerate.amazonaws.com
extra-trusted-public-keys = hhvm-nix-cache-1:MvKxscw16fAq6835oG8sbRgTGITb+1xGfYNhs+ee4yo=
sandbox = false
EOF
) &&
sudo launchctl remove org.nixos.nix-daemon && 
sudo launchctl load /Library/LaunchDaemons/org.nixos.nix-daemon.plist &&
sleep 3 &&
nix profile install 'git+https://github.com/facebook/hhvm.git?submodules=1&shallow=1&ref=refs/tags/nightly-2022.07.08' &&
hhvm --version

The above configuration is tested on Nix 2.9.1. The configuration for older Nix might be different.

How to Install a Different HHVM Version

The HHVM version to install is specified in the optional ref parameter in the URL, which can be any git branch or tag. For example:

• To install the latest development version of HHVM
  • nix profile install 'git+https://github.com/facebook/hhvm.git?submodules=1&shallow=1'
• To install HHVM nightly 2022.07.08
  • nix profile install 'git+https://github.com/facebook/hhvm.git?submodules=1&shallow=1&ref=refs/tags/nightly-2022.07.08'
• To install HHVM 4.164.0
  • nix profile install 'git+https://github.com/facebook/hhvm.git?submodules=1&shallow=1&ref=refs/tags/HHVM-4.164.0'
• To install the latest 4.164.* development version of HHVM
  • nix profile install 'git+https://github.com/facebook/hhvm.git?submodules=1&shallow=1&ref=refs/heads/HHVM-4.164'

Since HHVM is built with Nix for new HHVM versions only, the ref parameter must point to a child commit of 21870f6097ac7dea56ea57cc9113bcfd0d1a03d0.

Also note that the binary cache for a git commit would take hours of time to be available. If you are trying to install a recent commit, of which the binary cache is not available yet, Nix will build it from source for you automatically, otherwise Nix will just download the prebuilt binary.

How to Hack on HHVM In A Nix Development Environment

For Visual Studio Code Users

We provide a Visual Studio Code workspace to develop HHVM. To set up the VS Code based HHVM development environment on any Linux or macOS machines:

1. Install Nix
2. Checkout HHVM with all submodules: git clone https://github.com/facebook/hhvm.git --depth 1 --recurse-submodules
3. Open hhvm.code-workspace from Visual Studio Code
4. Install extension recommendations
5. Reload Visual Studio Code
6. Wait for the extensions to be activated. Note that it would take minutes to download dependencies, depending on your network speed.
7. Click the Build button from the CMake panel in Visual Studio Code

See this instructional video for more detail.

Using Development Containers Or GitHub Codespaces

Alternatively, we also provide a development container with Nix pre-installed, which can be either used in a local Docker engine or in GitHub Codespaces.

See this instructional video for more detail.

Working From The Command Line

To start a clean build HHVM from source:

1. Install Nix.
2. Checkout HHVM with all submodules: git clone https://github.com/facebook/hhvm.git --depth 1 --recurse-submodules
3. Under the work tree, run nix-build

To incrementally edit the source and build HHVM:

1. Install Nix.
2. Checkout HHVM with all submodules: git clone https://github.com/facebook/hhvm.git --depth 1 --recurse-submodules
3. Under the work tree, run nix-shell to enter a development shell. All the HHVM dependencies and development tools will be available in $PATH and other environment variables.
4. In the development shell, run cmake -C "$CMAKE_INIT_CACHE" -Bbuild to configure HHVM.
5. In the development shell, run cd build && make to build HHVM.
6. Make some changes to the source code.
7. In the development shell, run make to compile the affected files only.

Making Ad-hoc Changes

Feel free to directly edit files in the HHVM repository on GitHub website and create a pull request for ad-hoc changes. We have introduced GitHub Actions to build and test your pull requests with Nix. Just take the advantage from the CI signal and have fun!

HHVM 4.164 is released! 4.161 - 4.163 remain supported, as do the 4.128 and 4.153 LTS releases.

Highlights

• hh now rejects type aliases in catch blocks. These were already banned in the runtime (commit).
• Fixed an issue with incremental typechecks where making an XHP attribute required would not always show a type error (commit)
• Introduced the __Docs attribute on classes (commit)

HHVM 4.163 is released! 4.160 - 4.162 remain supported, as do the 4.128 and 4.153 LTS releases.

Highlights

• Added HH\str_bitwise_xor to perform bitwise xor operator on strings
• Relax restriction that prevents defaults and concrete type definitions with the same name in the same hierarchy. e.g. the following code now type checks:

  1
  2
  3
  4
  5
  6
  7
  interface I1 {
    const type T = int;
  }
  interface I2 {
    abstract const type T = float;
  }
  class C implements I1, I2 {}
  

Breaking Changes

• Removed the support to instance methods in Expression Trees

HHVM will no longer support homebrew on MacOS going forward.

We are continuing support for it on LTS releases (4.128 and 4.153) until they reach EOL, but we are stopping nightly builds of HHVM on MacOS homebrew, will no longer be publishing MacOS homebrew packages for new releases, and will not be testing new versions of HHVM on MacOS going forward.

Why are we doing this?

We are dropping support for two reasons. First, Homebrew has proven difficult to support. Dependency versions change out from under us which require retroactive fixes and back-porting retroactive fixes to LTS releases. Second, due to the current state of HHVM ARM support we are not able to provide a good experience on M1 Macs.

I use HHVM on MacOS homebrew, what should I do?

We recommend users on Intel macs switch to using one of our docker images. We are unable to support M1 users due to the different architecture and limitations of Rosetta. Therefore, we must recommend use of an Intel linux host instead.

HHVM 4.162 is released! 4.159 - 4.161 remain supported, as do the 4.128 and 4.153 LTS releases.

Highlights

• Autocomplete improvements to:
  • parent::__construct
  • the first keyword (e.g. the visibility keyword on a method) in the body of a class, interface, or trait
  • implements and extends
• Supports type refinements for readonly expressions
• A Hack property is now considered as a Field instead of a Property in an IDE
• Adds a lint rule for invalid XHP class enum values
• Passing an \Error as the $previous argument to the \Error constructor does not violate an internal typed property anymore. The argument to the constructor has/had the ?\Throwable type, but the $throwable->previous property had the ?\Exception type. Depending on the value of hhvm.check_prop_type_hints key in your configuration, this violation used to trigger a warning (the default), throw an \Error, or do nothing.

Breaking Changes

• Added stricter types for Exception, Error, and Throwable methods and properties

HHVM 4.161 is released! 4.157 - 4.160 remain supported, as do the 4.128 and 4.153 LTS releases.

Highlights

• Autocomplete stops offering type completions in top-level expressions, since no valid ones start with a type.
• Fixes a typechecker bug that didn’t allow a trait with a require class C constraint to access the protected members of the parents of C
• The docblock parser stops considering lines commented with // as part of the docblock if there are completely empty lines between that comment line and the definition being documented. This fixes some cases where file-level comments were being spuriously considered part of the docblock for the first thing defined in the file.
• The apc_fetch_with_pure_wakeup, apc_store_with_pure_sleep, and apc_add_with_pure_sleep APIs were published. These allow interacting with APC while enforcing that the __sleep and __wakeup magic methods won’t observe global state or produce side-effects.

HHVM 4.160 is released! 4.155 - 4.159 remain supported, as do the 4.128 and 4.153 LTS releases.

Highlights

• Autocomplete improvements to:
  • suggest function and class declarations at the top-level
  • suggest new method/property declarations in the body of a class
  • suggest method declarations in the body of an interface
  • suggest builtin attributes when typing an attribute name starting with _
• Add a quickfix that turns $shape['optional_field'] into Shapes::idx($shape, 'optional_field')

Breaking Changes

• The recently introduced attribute <<__SafeGlobalVariable>> has been renamed to <<__SafeForGlobalWriteCheck>>

As noted in the HHVM 4.153 release post, we are moving to releases every other week. The plan detailed in that post had us moving to releasing every 2 weeks starting after HHVM 4.156, but for administrative reasons that was delayed. As a result, this is the first week with no release, and this post is just a reminder of why. The next release (HHVM 4.160) is planned for next week.

HHVM 4.159 is released! 4.154 - 4.158 remain supported, as do the 4.128 and 4.153 LTS releases.

Highlights

• Add an attribute <<__SafeGlobalVariable>> to mark global variables as safe, ensuring no errors/warnings would be raised from writing to this global variable, when --enable-global-write-check is passed to hh_server. Note that this attribute will be renamed to <<__SafeForGlobalWriteCheck>> in the next release.
• Add a quickfix for missing switch fallthrough comment (// FALLTHROUGH).

Breaking Changes

• Make all array index read error codes the same. The error code 4435, 4298, and 4005 are replaced by 4324.

HHVM 4.158 is released! This release marks the end of support of 4.151; 4.153 - 4.157 remain supported, as does the 4.128 LTS release.

Highlights

• Add an autocomplete for enum values in switch statements
• Add a quickfix for missing async keywords

Breaking Changes

• Distinguish the HH_FIXME error code of direct writes to static variables. Now:
  • Error code 11001 represents directly writing to static variables.
  • Error code 11002 represents writing to global variables (that have references to static variables).
  • Error code 11003 represents passing global variables to function calls.
• Remove support for trait precedence and trait alias from HHVM.
• Remove support for the elseif keyword
• Turn on runtime enforcement for reading globals needs to be enclosed in readonly.
• This release breaks compatibility with older versions of hhvm/hhast. If hhast is used, it should be updated to version 4.158 together with this update.

HHVM 4.157 is released! This release marks the end of support of 4.150; 4.151 - 4.156 remain supported, as does the 4.128 LTS release.

Highlights

• New supported distribution: Ubuntu 21.10 (compiled with gcc 10)
• Bug fixes for __FILE__ and __DIR__ magic constants in traits
• Bug fixes related to postsend functions in the vsdebug debugger extension
• Initial work on supporting module-internal visibility
• Initial work on supporting multiple as/super constraints on a type constant

Breaking Changes

• This release breaks compatibility with older versions of hhvm/hhast. If hhast is used, it should be updated to version 4.157 together with this update.

HHVM 4.156 is released! This release marks the end of support of 4.149; 4.150 - 4.155 remain supported, as does the 4.128 LTS release.

Highlights

• A lint error is no longer raised for HH\FIXME_UNSAFE_CAST<mixed, T>($expr) if the type of $expr is non-denotable and expression-dependent, e.g. if IDE hover information or hh_client --type-at-pos shows a type like <expr#1>::T
• HH\serialize_with_options now supports a disallowObjects option, which disallows serialization of objects except for legacy Hack Collections.
• Numeric literals can now contain underscores to improve code readability; for example, $x = 1_234_567_890; sets $x to the integer 1234567890.
• Performance improvements for reified generics.
• All built-in attributes have IDE hover documentation.

Breaking Changes

• lambdas contained within an anonymous function will no longer implicitly capture variables from the parent scope of the anonymous function, unless the variable is in the anonymous function’s use clause

HHVM 4.155 is released! This release marks the end of support of 4.148; 4.149 - 4.154 remain supported, as does the 4.128 LTS release.

Highlights

• Added HHVM_COMPILER_TIMESTAMP constant to hhi for type checker, which contains the timestamp to build hhvm.
• Added narrower or pure capability declarations to the following builtin APIs:
  • create_opaque_value and unwrap_opaque_value
  • HH\Lib\Math\to_base
  • hash_*
• Permitted generic methods to override their own instantiations. e.g. function foo(int):int in a super class can be overridden as function foo<T>(T):T in a subclass.
• Allowed multiple --single options in hh_client invocations.
• Added a quickfix for missing awaitable type.
• Added hover docs for type aliases and contexts.
• Correctly handle negative and large integers passed to array_fill (See CVE-2022-27809).

Breaking Changes

• Enum class label expressions now requires defaults capability.
• Fixed an unsoundness allowing arithmetic expressions to be typed as int when one of the operands is an unsolved type.
• Moved all PERDIR ini settings to be SYSTEM settings.
• Deleted the runtime option Eval.EnableZendIniCompat.
• Removed the following options from HPHPc:
  • --force
  • --gen-stats
  • --sync-dir
  • --target
  • --program
  • --args
  • --include-path
  • --branch
  • --revision
  • --config-dir
• HPHPc now requires a --output-dir argument:
• Fixed an unsoundness due to type parameter name clash. e.g. given interface A<T> { function f<T1>(T $a): T1; }, if A is implemented in a class introducing type parameter name clash as class B<T1> extends A<T1> { function f<T1>(T1 $a): T1 { return $a; } }, when upcasting B to A, /*A<int>*/ $a = new B<int>();, it would allow for arbitrary type convention like Str\length($a->f(1));.

A security update has been released for all supported HHVM versions. Please update to one of the following versions to get the update:

• 4.128.4
• 4.148.1
• 4.149.1
• 4.150.1
• 4.151.1
• 4.153.1
• 4.154.1

This security update addresses:

• CVE-2022-27809, HHVM incorrect integer conversion in array_fill leads to uninitialized variable reference

HHVM 4.154 is released! This release marks the end of support of 4.147; 4.148 - 4.153 remain supported, as does the 4.128 LTS release.

Highlights

• IDE hover now shows original error messages for FIXME’d errors
• Fixed IDE hover for shapes (show the shape type) vs shape indexing (show the field type)
• IDEs should now suggest a void/Awaitable<void> return type for functions that do not return a value
• IDE error fix suggestions will now be provided regardless of if the error has a FIXME
• The HHVM Python/GDB scripts are now able to print SrcKey structs
• hphpd_break() and hphp_debug_break() can now be used in pure functions
• stream_get_meta_data() no longer crashes debug builds of HHVM when called on a closed file
• HH\Asio\curl_exec no longer has an unneeded exponential backoff

Breaking Changes

• The --hphp command (used for creating hhvm.hhbc for repo auth mode) interprets paths differently. On previous versions of hhvm --module . would include the current working directory in the repo. You must now explicitly provide all directories and files with Hack code using multiple flags, for example --module src --module vendor --ffile public/index.hack.

HHVM 4.153 is released! This release has long term support, so:

• this release will be supported for approximately 48 weeks
• the next LTS will be released in approximately 24 weeks
• HHVM 4.128 (LTS) and HHVM 4.147–151 remain supported
• support has ended for 4.102 (LTS) and 4.146

A final release of 4.102 - 4.102.7 - has been made to fix compatibility issues on MacOS.

Changing Our Release Cycle

We moved from monthly to weekly releases in 2019 due to the large rate of breaking changes, and the difficulty in keeping up with them; we believe that the severity of the breaking changes has decreased over time, and that the improved tooling and increased soundness of the language has changed this situation over the last few years.

We aim for 4.156 to be the last weekly release, and will then be moving to a two-week release schedule; we hope that this is a stepping stone on the way to a monthly release cycle, with an eventual goal of it being practical for the community to primarily target our LTS releases. We actively welcome feedback, and are open to reverting back to weekly releases if it is best for the commuinty.

We hope that this move will reduce work for community maintainers, and make standard approaches such as semantic versioning more practical.

Highlights

• Added function/method name to typechecker error messages for access to global variables in contexts without the necessary capabilities.
• Added \HH\Lib\OS\posix_spawnp and \HH\Lib\OS\posix_spawn, which supports a subset functionality of the corresponding POSIX C API.
• Added getopt_with_optind native function to support simple subparsers.
• When an untyped lambda is passed as nonnull, the body is now typechecked as if the untyped parameters were mixed instead of nonnull, which is consistent with passing an untyped lambda as mixed or dynamic (where parameters are assumed to be mixed or dynamic, respectively). Previously, passing an untyped lambda as nonnull would always raise error 4224: “Cannot determine types of lambda parameters in strict mode”.
• crc32q instructions are now used for improved performance when HHVM is built on for a compatible target.
• refactored typechecker errors for missing interface methods to flow more naturally and clarify the relationship between the various parts of the error and source filenames and line numbers.
• improved readability of typechecker errors when subclass members are incompatible with a supertype.
• LSP-compatible IDEs will now offer a quickfix to remove async from interface methods. async interface methods and abstract methods are already an error, as it is an implementation detail - the Awaitable<T> return type specifies how it is called.
• Added a quickfix for nonexistent type name in params
• Added a quickfix for missing new
• added IDE hover information for built-in types
• inout parameters can now be dynamic.
• pcntl_waitpid() and pcntl_wait() now work correctly in server modes - proxygen, fastcgi, and CLI-server
• added File\leaky_temporary_file() which requires manual closing and deletion. File\temporary_file() remains strongly encouraged where possible.
• resources can now be passed as dynamic. resource remains strongly discouraged in cases where alternatives exist.

Breaking Changes

• Fix unsoundness with closure properties in readonly check. For example ($this->f)() now requires readonly check if the return type of f is readonly.
• Fix missing bound on Set keys; (Set {})->add($non_arraykey) now properly raises a type error.
• <<__ProvenanceSkipFrame>> has been removed from the HSL; this was an unsupported annotation that was previously intended for PHP array to vec/dict/keyset migration.
• unset statement parameters can no longer contain function calls.
• The proxygen server no longer supports TLS v1.0 or v1.1. Plain HTTP and TLS v1.2 or above are still supported.

HHVM 4.151 is released! This release marks the end of support of 4.145; 4.146 - 4.150 remain supported, as do the 4.102 and 4.128 LTS releases.

Highlights

• Added IDE hover information for class constants when the type is inferred.
• hphpd_break and hphp_debug_break are now marked as pure.
• Add an IDE quickfix for non-existent type names.
• Adds a new constant (HHVM_COMPILER_TIMESTAMP) and read-only ini setting (ini_get('hphp.compiler_timestamp')) that contain the timestamp to build hhvm (which is itself part of the HHVM_COMPILER_ID and hphp.compiler_id constant and ini setting).
• abstract enum class is not considered an experimental feature any more.

Breaking Changes

• The key type of a dict or a keyset is now always inferred as a subtype of arraykey even when used with dynamic. For example, previously the key type could be inferred as types like int|dynamic and now it would be int|(dynamic&arraykey) in that case.

HHVM 4.150 is released! This release marks the end of support of 4.144; 4.145 - 4.149 remain supported, as do the 4.102 and 4.128 LTS releases.

Highlights

• The ENT_HTML5 constant is now recognized by the typechecker
• Added getSslCertCn(), getSslCertSan(), getSslCertExtensions(), and isSslCertValidationEnforced() to AsyncMysqlResult and AsyncMysqlConnection
• Added $server_cert_values parameter to AsyncMysqlClient::connect(), which contains comma separated values that are matched against the existing $cserver_cert_extensions parameter when verifying the certificate.
• class_implements(), class_parents(), and class_uses() are now marked as pure
• If a function is marked as returning mixed but returns without a value, LSP-based IDEs such as VSCode will now suggest void or Awaitable<void> return types
• LSP-based IDEs will now show Vector/Map/Set documentation comments on hover for literals, not just the types
• LSP-based IDE hover information for shape elements will now show information type information the specific element, not the shape as a whole
• HH\Readonly\Shapes now includes typechecker definitions

Breaking Changes

• AsyncMysqlClient::adoptConnection() has been removed.
• It is now a type error to use meth_caller() on methods that return a readonly object; previously, this would be a runtime error. This is due to technical limitations of the current implementation.
• If a memoized function is called from a context that does not have the write_globals capability, a more specific error is raised based on the write or passing of the return value (if mutable), instead of always when the function is called. This may change necessary fixme codes from 4461 (“a memoized function is called”) to 4459 (“A global variable is written”).
• Removed `HH\class_get_class_name()

As of HHVM version 4.139, we’ve released a new keyword called readonly in Hack. readonly is a new feature in Hack for restricting the mutability of object properties. It’s designed for use cases that require performant, runtime-enforced mutability control.

readonly has two main principles: readonlyness and deepness.

• Readonlyness: Object properties of any readonly value cannot be modified (i.e. mutated).
• Deepness: All nested properties of a readonly value are readonly.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Bar {
  public function __construct(
    public Foo $foo,
  ){}
}
class Foo {
  public function __construct(
    public int $prop,
  ) {}
}

function test(readonly Foo $foo, readonly Bar $bar) : void { 
  $foo->prop = 5; // error, $foo is readonly 

  // Deepness: $x is also readonly
  $x = $bar->foo;

  $x->prop = 3; // error, $x is readonly
}

The readonly keyword can be used in many places in Hack.

• Readonly expressions: Any expression can be marked readonly with the readonly keyword.
• Readonly parameters: A parameter marked readonly signal that a function or method can take in a readonly value, and does not modify it.
• Readonly return types: A function can return readonly, which allows it to return a readonly reference.
• Readonly properties: A property can be marked readonly, which allows you to assign a readonly value to it. Note that readonly properties can have their values replaced, as readonly is a modifier on the value of the property, not the property definition itself.
• Readonly methods: An instance method can be marked readonly. Instance methods that are readonly treat $this as readonly. Readonly values can only call readonly methods.
• Readonly closures: A readonly closure captures external variables as readonly.

You can see some examples of the readonly keyword in this code snippet:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
class Bar {
  public int $prop = 0;
}
class Foo {
  public function __construct(public Bar $bar, public readonly Bar $ro_bar) {}

  // This method promises not to modify $this
  public readonly function getBar(): readonly Bar {
    // note that $this is readonly, so $this->prop is readonly, which is why
    // this method must return readonly
    return $this->bar;
  }

  public static function takesReadonlyExample(readonly Foo $x): void {
    $x->bar = new Bar(); // error, $x is readonly here!
  }

  public static function readonlyClosureExample(): void {
    $x = new Bar();
    $readonly_f = readonly (): void ==> {
      $x->prop = 5; // error, $x is captured as readonly since $readonly_f is a readonly function
    };
    $x->prop = 4; // $x is still mutable out here, so this is okay!
  }

  public function readonlyPropExample(Foo $foo): void {
    $x = readonly new Bar();
    $foo->bar = $x; // error, $x is readonly but bar is a regular property
    $foo->ro_bar = $x; // ok!
  }
}

Some function calls and property accesses require explicitly annotating the result of the call as readonly:

• If you call a function that returns a readonly value, you must annotate the call with the readonly keyword.
• If you access a class’s readonly property, you must annotate the access with the readonly keyword.

1
2
3
4
5
6
function testExplicitReadonly(readonly Foo $foo): void {
    //     vvvvvvvv This keyword is required here since getBar returns readonly
    $bar = readonly $foo->getBar(); 
    //             vvvvvvvv This keyword is required here since $ro_bar is a readonly property
    $ro_bar_prop = readonly $foo->ro_bar;
}

For a full guide and specification to using readonly, you can check our full documentation on the feature.

HHVM 4.149 is released! This release marks the end of support of 4.143; 4.144 - 4.148 remain supported, as do the 4.102 and 4.128 LTS releases.

Highlights

• __clone is now able to write to its own properties even when the capability set is specified as pure.
• Add coeffects to the following builtin APIs:
  • class_*
  • dyncall_*_force
  • ReflectionProperty::{get,set}Value
  • Reflection{Method,Property}::setAccessible
  • thrift_protocol_set_compact_version
  • mb_*
• Fix segment fault when the locale specified in $LANG is not found.

HHVM 4.148 is released! This release marks the end of support of 4.140; 4.143 - 4.147 remain supported, as do the 4.102 and 4.128 LTS releases.

Highlights

• Fixed error where libelf may not be found
• Autocomplete now suggests enum values for function parameters
• Added HH\Readonly\Shapes class, partially mirroring the Shapes class
• HH\Lib\Str\length() now takes advantage of JIT optimizations that were previously exclusive to \strlen()

Breaking Changes

• function bodies are now required for non-builtin functions.

HHVM 4.147 is released! This release marks the end of support of 4.139; 4.140, and 4.143 - 4.146 remain supported, as do the 4.102 and 4.128 LTS releases. 4.141 and 4.142 were cancelled due to the holiday season.

Highlights

• Add coeffects to thrift_protocol_set_compact_version, DateTime and mbstring functions.
• Support hover and go-to-definition on type parameters in an IDE.
• Support hover and go-to-definition on the abstract keyword in an IDE.

Breaking Changes

• The result of HH\FIXME\UNSAFE_CAST is now considered readonly if the input is readonly.
• Always raise an error when inheriting members that differ only by case (previously the error would be raised only if case_sensitive_inheritance option is enabled)

HHVM 4.146 is released! This release marks the end of support of 4.138; 4.139, 4.140, and 4.143 - 4.145 remain supported, as do the 4.102 and 4.128 LTS releases. 4.141 and 4.142 were cancelled due to the holiday season.

Highlights

• If options to log or forbid dynamic calls to class (static) methods are enabled, logging/errors will no longer be raised by calls to static methods on reified generics, e.g. T::foo();.

Breaking Changes

• Coeffect violations now throw a CoeffectViolationException instead of a BadMethodCallException; both extend LogicException.
• It is now a parse error to declare a lambda/method/fuction parameter called $this; previously, any attempts to use it would be treated as references to the current object instance, not the parameter.
• ob_get_contents(), ob_get_length(), ob_get_level(), ob_get_status, ob_list_handlers(), hphp_get_stats(), hphp_get_status(), hphp_get_io_status(), hphp_get_timers(), hphp_instruction_counter(), and hphp_get_hardware_counters() are now marked as [read_globals], so can no longer be called from ‘pure’ functions.
• diamond hierarchies of traits (traits with a shared parent trait) are banned if the traits define generic properties as it can be unsound.

HHVM 4.145 is released! This release marks the end of support of 4.137; 4.138, 4.139, 4.140, 4.143, 4.144 remain supported, as do the 4.102 and 4.128 LTS releases. 4.141 and 4.142 were cancelled due to the holiday season.

Highlights

• Support throw on dynamic, e.g. function foo(dynamic $d): void { throw $d; }
• Attributes on class constants do not result errors any more (assessing the attributes via runtime reflection is still not yet supported)
• The built-in function gethostname is now a pure function.

Breaking Changes

• Raise the typing error 4068 on ?mixed and similar if they’re in a type hint position, including f<?mixed>() or new C<?mixed>().
• Reject calls in l-value position, such as (foo($x))[3] = 'a' or (bar($y))[] = 45.
• The built-in function curl_multi_exec now requires int as the second parameter.

HHAST is a toolkit for for analyzing the structure of Hack files. It includes a linting and migration framework to find and automatically fix problems in your code. The lint errors and migration suggestions can be accessed from Hack API, command line interface or IDEs.

HHAST also ships with many built-in lint rules and migration rules. However, the HHAST built-in lint rules have limited access to the type checker, therefore, it is difficult to create a lint rule that needs to determine questions like “is this type a subtype of that type?” or “is this expression compatible with that function signature?”.

Recently, we released HHAST v4.139.0. The new version brings a proxy to run the linter from the Hack compiler written in OCaml, which includes more powerful lint rules that need the access to the type checker ¹. Note that type checker based lint rules cannot be user-defined, as they must be written in OCaml, built in to the HHVM repository.

How to enable type checker based lint rules?

Firstly, follow the User Documentation to set up the linters for IDEs and command line tools.

The lint rules from the Hack compiler are not enabled by default, to enable them, put the following settings into your hhast-lint.json:

1
2
3
"extraLinters": [
  "Facebook\\HHAST\\HHClientLinter"
],

HHClientLinter is the special linter as a proxy to run linters from the Hack compiler. Similar to the Hack typing errors, these lint rules report lint errors with 4-digit numeric codes. To avoid conflicts, the 5xxx range is reserved for Hack compiler lint rules.

Run HHClientLinter for particular error codes

HHClientLinter can be configured to not report particular error codes by adding the following settings into your hhast-lint.json

1
2
3
4
5
"linterConfigs": {
  "Facebook\\HHAST\\HHClientLinter": {
    "ignore": [5624, 5639]
  }
}

or if you are interested in only particular error codes:

1
2
3
4
5
"linterConfigs": {
  "Facebook\\HHAST\\HHClientLinter": {
    "ignore_except": [5624, 5639]
  }
}

The definition of error codes can be found at lints_codes.ml.

Suppressing error codes in a file

Each lint error can be suppressed separately with the help of HHAST_IGNORE_ERROR markers.

For example, suppose you are generating a file including some unnecessary null checks, which triggers the error code 5611, putting the HHAST_IGNORE_ERROR[5611] marker at the previous line of each lint error position could prevent HHAST from reporting it.

1
2
3
4
5
6
7
8
9
10
11
class Diagnosis {
  public function __construct(shape('file' => string, 'position' => ?int, 'reason' => string) $data) {}

  public function hasFile(): bool {
    // HHAST_IGNORE_ERROR[5611]
    return $this->data['file'] is nonnull;
  }
  public function getFile(): string {
    return $this->data['file'];
  }
}

HHAST_IGNORE_ALL is also supported for suppressing an error code in the whole file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// HHAST_IGNORE_ALL[5611] because this file is generated.
// It is expected to include some correct but unnecessary null checks.
class Diagnosis {
  public function __construct(shape('file' => string, 'position' => ?int, 'reason' => string) $data) {}

  public function hasFile(): bool {
    return $this->data['file'] is nonnull;
  }
  public function getFile(): string {
    return $this->data['file'];
  }
  public function hasPosition(): bool {
    return $this->data['position'] is nonnull;
  }
  public function getPosition(): ?int {
    return $this->data['position'];
  }
  public function hasReason(): bool {
    return $this->data['reason'] is nonnull;
  }
  public function getReason(): string {
    return $this->data['reason'];
  }
}

HHAST_IGNORE_ALL is not encouraged because, unlike HHAST_IGNORE_ERROR, HHAST_IGNORE_ALL would silently skip newly introduced errors and you would miss the opportunity to review them.

References

• HHAST Github Project
• HHAST User Documentation
• HHAST 4.139.0 Release Note
• Lint Error Code Definition

HHVM 4.144 is released! This release marks the end of support of 4.136; 4.137, 4.138, 4.139, 4.140, 4.143 remain supported, as do the 4.102 and 4.128 LTS releases. 4.141 and 4.142 were cancelled due to the holiday season.

Highlights

• The type checker now truncates the error message when printing out a type, in case of hanging the type checker if the type is complicated. The threshold can be configured via the hh_client --config type_printer_fuel=N option.
• classname<E> where E is an enum now supports dynamic.

Breaking Changes

• Local coeffects are enforced at runtime (previously coeffect errors were only reported in the type checker, not runtime).
• An error will be thrown when a global is accessed in a read_globals context without an enclosing readonly modifier.

HHVM 4.143 is released! This release marks the end of support of 4.135; 4.136–4.140 remain supported, as do the 4.102 and 4.128 LTS releases. 4.141 and 4.142 were cancelled due to the holiday season.

Additional patch releases have been made for 4.102, 4.128, and 4.135-4.140, which change the typechecker to ignore any files in vendor/bin/; this is required for compatibility with Composer 2.2.

Highlights

• Compatible with Composer 2.2.
• Added documentation on hover for readonly, extends, async, await, and concurrent keywords.
• fb_intercept2() now supports functions that return readonly.

Breaking Changes

• If an interface or class is <<__ConsistentConstruct>> but does not define a constructor, all subclass constructors must now be pure ([]). Alternatively, define a constructor on the interface or class to specify different capabilities. In previous versions, this can be enabled with the pure_default_consistent_constructors flag in .hhconfig.
• DateTimeInterface::getTimestamp() is now pure; any custom implementations will need to also be pure.

HHVM 4.139.1 and HHVM 4.140.1 are released! These releases add support for a new environment variable, HHVM_DISABLE_PERSONALITY, which disables use of the personality() syscall on Linux.

Like HHVM_DISABLE_NUMA, this is required in some restricted environments, such as Docker containers, and is now set in our Docker images for these versions.

HHVM 4.140 is released! This release marks the end of support for 4.134; HHVM 4.135–4.139 remain supported, as do the 4.102 and 4.128 LTS releases.

v4.140 is the last release in 2021. Happy Holidays!

Highlights

• Various bug fixes for the readonly data types.
• Various error message improvements.
• The typechecker now understands the coeffects of \preg_replace_callback() and \preg_replace_callback_with_error(). See this commit for the new signature.

Breaking Changes

• JitAHotSize and JitAProfSize runtime options are removed
• Ban UNSAFE_CAST in lvalues and await operands. The following code does not type-check any more:
  • HH\FIXME\UNSAFE_CAST<mixed, dict<int, string>>($m)[0] = "lvalue";
  • await HH\FIXME\UNSAFE_CAST<Awaitable<mixed>, Awaitable<int>>(foo());
• Now a clone of a readonly object is also readonly.
• The functions \preg_replace_callback() and \preg_replace_callback_with_error() now take a (function(darray<arraykey, string>)[_]: string) as the second parameter in the typechecker, instead of an untyped value.

HHVM 4.139 is released! This release marks the end of support for 4.133; HHVM 4.134–4.138 remain supported, as do the 4.102 and 4.128 LTS releases.

December release schedule

We expect to release 4.140 next week, but there will be no 4.141 release (week of the 20th), or 4.142 (week of the 27th). We plan to resume our usual schedule with 4.143 in the week of the 3rd of January, however we consider this release ‘at-risk’, depending on changes during the preceeding weeks.

Highlights

• Hack now supports readonly data types.
• Reliability of the VSCode debugger interface has been improved.
• The IDE quickfix for missing methods now creates async stub methods if the return type is Awaitable.
• Added IDE quickfix for int, float, or string constants that are declared without a type.
• json_decode() is now faster, and consumes less memory.

Breaking Changes

• It is now an error to read static properties in functions that do not have the globals or read_globals capabilties.
• It is now an error to write static properties in functions that do not have the globals capabilty.
• json_decode() is now stricter about the input it accepts (per JSON/ECMA-404):
  • leading 0s are no permitted in fewer situations; for example, they are now banned as object field values when returning a dict.
  • \f is no longer considered a whitespace character.
  • \r is now considered a whitespace character.

HHVM 4.138 is released! This release marks the end of support for 4.131; HHVM 4.133–4.137 remain supported (4.132 was cancelled), as do the 4.102 and 4.128 LTS releases.

This release primarily contains changes that are not easily observable, such as reliability improvements and preparation work for future changes.

Highlights

• regex functions correctly handle the /A modifier with non-zero offsets (regression fix)

HHVM 4.137 is released! HHVM 4.131–4.136 remain supported, as do the 4.102 and 4.128 LTS releases. HHVM 4.131 remains supported as the 4.132 release was cancelled.

Highlights

• hh_client --lint no longer suggests that reified generic parameters should be marked as covariant or contravariant, as this is not supported for reified generic.
• IDEs now suggest replacing self with static when calling an abstract static method.
• Improved the accuracy and message clarity of the ‘always false’/’always true’ built in linter when a condition is always true/false due to is/as checks.

HHVM 4.136 is released! HHVM 4.131–4.135 remain supported, as do the 4.102 and 4.128 LTS releases.

Highlights

• Add IDE quickfix for missing interface methods.
• The readonly feature is no longer considered unstable.
  • The readonly modifier is now also visible to the reflection API via the isReadonly() or returnsReadonly() functions.
• The WriteHandle::truncate method is added to HSL to truncate files.
• Various APIs in HSL are now considered pure or controlled and no longer require the defaults capabilities.
• The noreturn type now can be upcasted to dynamic.

Breaking Changes

• Methods with a private final modifier are not supported any more. Use private instead.
• The partial typing mode is removed. This includes both support for <?hh // partial in .php files, and for .hackpartial files.
• Raise an error when a trait is <<__ConsistentConstruct>> but does not declare an explicit constructor.

HHVM 4.135 is released! HHVM 4.130–4.134 remain supported, as do the 4.102 and 4.128 LTS releases.

This release primarily contains stability and performance improvements, and work towards future features that are not yet supported.

Highlights

• If using Watchman, fixed a potential deadlock when connecting.

Breaking Changes

• If a function intercept handler throws an exception, the intercepted functions’ exception handler is no longer used.

Future Changes

• We are now actively working towards removing support for ‘partial’ mode.

HHVM 4.134 is released! HHVM 4.129–4.133 remain supported, as do the 4.102 and 4.128 LTS releases.

Highlights

• ext_curl will now cache TLS certificates between requests if HHVM is built against Curl v7.46.0 or newer.
• added HH\Lib\Ref::get() and ::set($value) - direct property access is still supported.
• Added HH\Lib\Async\Poll::waitUntilEmptyAsync() for convenience and clarity when only the side effects of the Awaitables are needed, such as when running an event loop.

Breaking Changes

• It is now an unfixmeable parse error to attempt to write to object properties in a pure function.

HHVM 4.133 is released! HHVM 4.128–4.131 remain supported, as do the 4.102 and 4.128 LTS releases. HHVM 4.132 was skipped due to issues with the nightly builds.

Highlights

• dynamic values can now be used as container keys. The containers will then be inferred to be keyed by arraykeys, so can not be used as T<int, _> or T<string, _>.
• if a debugger is attached, the JIT will never be used, and the JIT will never be disabled in the middle of a request for the debugger. This improves debugger reliability.
• fixed order-dependent autoloader issues for enum classes including other enum classes.
• when a static property is used as an instance property, the error message now correctly says ‘static property’ instead of ‘static method’.
• fixed Str\format() accidentally using the request locale.
• fixed hackfmt adding unwanted blank lines to the top of files.
• updated build environment to OCaml 4.12 and Rust/Cargo v2021.10.21.

Breaking Changes

• hash comments are no longer supported, and are a parse error. Use // comments instead.
• Files without a .php, .hack, .hackpartial, or .hhi extension will now be consistently parsed as if they were .hack files.
  • previous behavior was context-dependent.
  • this change includes both files with other extensions, and files with no extension.
  • this may break legacy extensions such as .hck and .hh, as <?hh tokens are banned in .hack files.
• it is now an error to call parent::__construct() from a trait, unless the parent has <<__ConsistentConstruct>>.
• it is now an error for a constructor to read properties defined by a parent class before calling parent::__construct().
• updated Thrift and mcrouter versions to v2021.11.18; supporting libraries and tools may need an update if you are using these extensions.

Future Changes

• .php files remain deprecated, and support may be removed in a future release; .hack is strongly recommended instead
• .hackpartial and .php files with <?hh // partial remain deprecated, and support will likely be removed in a future release. .hack is strongly recommended instead.

HHVM 4.131 is released! HHVM 4.126–4.130 remain supported, as do the 4.102 and 4.128 LTS releases.

Highlights

• Breakpoints in Visual Studio Code no longer require the legacy debugger to be enabled.
• Added AsyncMysqlConnectionPool::connectAndQuery().
• Fixed ReflectionTypeConstant::getTypeStructure() incorrectly referring to the declaring class for inherited type constants, instead of the current class. This could lead to bugs if the type constant referred to this.
• Fixed a memory leak in Str\replace functions introduced in 4.130

HHVM 4.130 is released! HHVM 4.124–4.129 remain supported, as do the 4.102 and 4.128 LTS releases.

Security Advisory

Vulnerabilities have been found bypassing the intent of the hhvm.server.whitelist_exec, hhvm.server.whitelist_exec_warning_only, and hhvm.server.allowed_exec_cmds options when subprocesses are executed via system() (and potentially similar APIs such as shell_exec() and proc_open()) with user-controlled input. Given that these builtins all execute subprocesses via a shell, there is not a viable path to implement these in a trustable way, so these options will be removed without replacement in a future release.

We recommend:

• refactoring application code to avoid user-controlled subprocess command lines. The escapeshellarg() function may be useful here, but assumes a sh-style shell.
• if user-controlled subprocess command lines are absolutely unavoidable, use containers, jails, or operating-system-provided mechanisms to implement subprocess restrictions.

Highlights

• Improved error message source locations for errors related to inout parameters.
• Fixed various issues with breakpoints not triggering, for example, when set in lambdas. Breakpoints currently require that the legacy debugger is enabled with hhvm.debugger.enable_debugger=1, even if using a different debugger such as Visual Studio Code. We expect to remove this requirement in a future release.
• added Locale\bytes() as a preferred alias for Locale\c(); we expect to remove Locale\c() in a future release.
• hh_client --lint can now suggest variance; for example:

    Lint[5639] This generic parameter could be marked covariant. Consider prefixing the generic parameter with + [1]

    infer_variance.php:1:19
    [1] 1 | interface IGetter<T> {
        2 |   public function get(): T;
        3 | }

Breaking Changes

• It is now an error to pass the first argument to invariant() as inout.
• Using self and parent as types now results in a runtime error; this previously raised typechecker errors. They remain valid for use in other contexts, e.g. self::foo() and parent::__construct().
• array_map() is no longer special-cased in the typechecker; it now expects a single callback, a single KeyedContainer, and returns a KeyedContainer. It no longer accepts a variable number of parameters, and no longer preserves the concrete type of the input.
• The Str\ functions no longer respect the current thread locale; functions that were locale-sensitive now have a _l() variant that takes an explicit locale.
  • For example, Str\format('%0.2f', 1.23) will now reliably return 1.23, instead of sometimes returning 1,23 - if the previous behavior is desired, Str\format_l(Locale\get_native(), '%0.2f', 1.23) can be used instead.
  • We made this change as implicit use of the locale meant that the majority of Str\ functions could not be marked as pure, and because most users were surprised that functions like Str\format(), sprintf() etc were locale-aware.
  • The _l functions support UTF-8, depending on the CTYPE in the locale; this may lead to behavior differences. Please ensure that LC_CTYPE is set correctly for the behavior you desire using Locale\modified().
• Str\split() now consistently throws if a negative limit was provided.
  • previously, Str\split() would only throw for negative limits if the delimiter was empty.
  • the previous behavior was unintuitive, and inconsistent with other functions that accept negative limits with offsets:
    • Str\split('a!b!c', '!') returned vec['a', 'b', 'c']
    • Str\split('a!b!c', '!', 2) returned vec['a', 'b!c']
    • Str\split('a!b!c', '!', -1) instead returned vec['a', 'b']
  • added Legacy_FIXME\split_with_possibly_negative_limit() as a migration aid with the old behavior.
• Str\replace_every() and related functions now consistently raises exceptions for empty search strings, and for inputs that are not strings. Previous behavior varied depending on the specific function and inputs.
  • added Legacy_FIXME\coerce_possibly_invalid_str_replace_pairs() as a migration aid.
• Str\ functions now raise InvalidArgumentException instead of invariant violations for invalid arguments.

Future Changes

• We may remove implicit int/string coercion of enum values in a future release; if the hhvm.warn_on_implicit_coercion_of_enum_value flag is set to true, the runtime will raise a warning. This affects is and as operators, and EnumName::isValid().

HHVM 4.129 is released! This release marks the end of support for 4.123; HHVM 4.124–4.128 remain supported, as do the 4.102 and 4.128 LTS releases.

Highlights

• hackfmt --in-place (or -i) no longer writes to files that do not have formatting changes.
• added hackfmt --check-formatting which, given a list of files, prints which files would be modified by hackfmt --in-place.
• hackfmt now correctly handles multi-line string literals.
• fixes DateTimeZone::listIdentifiers() returning an empty set.
• fixes the UTC timezone not being recognized.

Breaking Changes

• isset() no longer permits inout arguments.
• Many built-in exceptions including RuntimeException and LogicException now extend the new ExceptionWithPureGetMessage class; all descendents that override getMessage() must mark it as pure, e.g. getMessage()[].

HHVM 4.128 is released! This release has long term support, so:

• this release will be supported for approximately 48 weeks
• the next LTS will be released in approximately 24 weeks
• HHVM 4.102 (LTS) and HHVM 4.123–127 remain supported
• support has ended for 4.80 (LTS) and 4.122

Highlights

• Compatible editors (e.g. Visual Studio Code) will now suggest fixes for some type errors, such as undefined variable names that appear to be typoes.
• hackfmt -i (or --in-place) now accepts multiple filenames in one invocation.

Breaking Changes

• newctx now requires an as constraint.

HHVM 4.127 is released! This release marks the end of support for 4.121; HHVM 4.122–4.126 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• Clearer typechecker errors when an attribute is passed the wrong number of arguments.
• add Str\foo_l() functions taking a Locale\Locale() object, and supporting UTF8 (via Locale\create('en_US.UTF-8'), for example). We recommend only using these functions when locale or multibyte-character awareness is explicitly required, as:
  • the non-_l functions are more performant
  • the implementation works on normalized UTF-16, which can mean that a Str\ends_with_l() call returns true when a string ends with the same characters, but in a different byte sequence, potentially of a different length.
• Corrected behavior of __FILE__ in trait methods.
• Added crypto_core_ristretto255_from_hash() and sodium_crypto_scalarmult_ristretto255() when supported by system libsodium.
• Added the sodium_crypto_secretstream family of functions.
• Updated hackfmt’s formatting of assignments with long assignment values. Now hackfmt prefers to break the whole assignment value onto a new line. You can preserve the old newline handling with hackfmt.version = 0 in your .hhconfig.

Breaking Changes

• The .hhconfig flag disallow_partially_abstract_typeconst_definitions is now true by default, and will be removed in a future release. This bans declarations of the form const type T as Y = Z.
• foo()::$static_prop = 1 is now a runtime error, instead of only a typechecker error.

HHVM 4.126 is released! This release marks the end of support for 4.120; HHVM 4.121–4.123 remain supported, as do the 4.80 and 4.102 LTS releases.

HHVM 4.125 was cancelled due to issues with the release candidate builds.

Highlights

• hh_client --lint FILE is now supported, including several type-aware linters. There is not currently any configuration or suppression available; please join us in Slack to discuss potential integration approaches.
• Debian 11 (Bullseye) is now supported.
• Updated to a newer version of Timelib, fixing support for newer timezone databases; in some environments, some transitions would be missing.
• is/as checks will now invoke the autoloader if required instead of failing.
• Improved build system reliability and performance for Hack components used by the runtime (e.g. the parser).
• Added the HH\Lib\Locale namespace, providing:
  • Locale\create(string $locale)[]: Locale\Locale
  • Locale\modified(Locale\Locale $base, Locale\Category $cat, string $new): Locale
  • Locale\c()[]: Locale\Locale (likely to be renamed to Locale\bytes())
  • Locale\get_native(): Locale\Locale
  • Locale\set_native(Locale\Locale $locale): void
  • Locale\from_environment(): Locale\Locale

The new Locale\ functions are intended to be a replacement for the setlocale() built-in, and to interoperate with future changes to the Str\ namespace.

We discourage changing the native locale in most cases (either with setlocale() or with the new Locale\set_native()) as it can have unexpected results, such as changing the output of Str\format(), or translating exception messages raised by some builtins which should usually end up in logs that are read by developers/administrators instead of users. We have included it to provide a migration path for existing users of setlocale(), and because it is desirable in some cases, especially CLI tools.

Breaking Changes

• Ubuntu 20.10 (Groovy) is no longer supported, as it reached end of life in July.

Future Changes

• Str\ HSL functions will start throwing InvalidArgumentException instead of InvariantException when invalid offsets or lengths are passed. We strongly recommend against catching either of these exceptions.
• In a future release, it will be an error to iterate over most forms of objects; this can be tested now with the hhvm.throw_on_iteration_over_objects INI setting. Set to 1 for a notice to be raised, or 2 for an error.

HHVM 4.124 is released! This release marks the end of support for 4.118; HHVM 4.120–4.123 remain supported (4.119 was skipped), as do the 4.80 and 4.102 LTS releases.

This release primarily contains improvements to implementation details, and preparatory work for future features/changes.

Future Changes

• Str\ HSL functions will start throwing InvalidArgumentException instead of InvariantException when invalid offsets or lengths are passed. We strongly recommend against catching either of these exceptions.

HHVM 4.123 is released! This release marks the end of support for 4.117; HHVM 4.118–4.122 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• Improved typechecker error messages when refining objects to a class that doesn’t exist.
• Indexing containers with covariant keys now results in a distinct, clearer, error (4449) if the key type is incompatible. Some FIXMes may need changing.
• LSP-based IDEs may now suggest quickfixes when calling typoed static/instance methods.

Breaking Changes

• Arguments to meth_caller() must now be constants

HHVM 4.122 is released! This release marks the end of support for 4.116; HHVM 4.117–4.121 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• Improved JIT performance of non-async generators.
• Separately improved the JIT performance of async generators.
• HSL IO’s `BufferedReader::readByteAsync’ now operates correctly if a read happens with an empty buffer (usually at the 8kb boundary).
• Fixed bug leading to crash when INI files reference environment variables.

Breaking Changes

• == no longer converts types or warns by default; false is now returned. For example, var_dump(1 == '1') prints bool(false).
• comparison operators (e.g. <) now throw in cases where they would previously coerce types, such as 1 < '2'.
• hh_single_compile is no longer included in our packages. HackC is now embedded in HHVM as a library. If you want to view the generated bytecode (e.g. for debugging), use hhvm -d hhvm.dump_hhas=1 foo.hack.
• gettype() will no longer ever return array - vec, dict, or keyset will be returned instead. If you need to distinguish between arrays marked as legacy and other arrays, use HH\\is_array_marked_legacy($x).
• Removed curl_copy_handle and CurlPool due to thread safety issues. If similar behavior is required, we recommend using CurlShareHandle instead.

HHVM 4.121 is released! This release marks the end of support for 4.115; HHVM 4.116–4.120 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• When converting bools/resources/objects to ints, only raise a conversion notice or error, not both.
• Added a new hhvm.notice_on_coerce_for_str_concat2 option to catch a coercion case that is not handled by hhvm.notice_on_coerce_for_str_concat. For both of these, a value of 0 means silent coercion, 1 raises a notice, and 2 is an error.

Breaking Changes

• Errors are now raised by default when math operations have to implicitly coerce the type of an operand. This includes increment and decrement operators. In prior versions, this behavior can be controlled with the hhvm.notice_on_coerce_for_math and hhvm.notice_on_coerce_for_inc_dec INI settings.
• A notice is now raised when comparison operators coerce types. This can be controlled with the hhvm.notice_on_coerce_for_cmp and hhvm.notice_on_coerce_for_eq INI settings.
• Bitwise operations now raise an error when coercing types. On previous releases, this can be controlled with the hhvm.notice_on_coerce_for_bit_op INI setting.

See 4.120’s announcement for Legacy_FIXME functions to aid in type coercion migration.

Future Changes

• The various coercion options will be removed over time, and implicit coercions will always be errors.

HHVM 4.120 is released! This release marks the end of support for 4.113 and 4.114; HHVM 4.115–4.118 remain supported, as do the 4.80 and 4.102 LTS releases. HHVM 4.119 was skipped due to personal circumstances of the team.

Highlights

• autocomplete can now provide documentation for suggestions
• autocomplete now understands built-in primitive types like string
• stream_select() and pagelet_server_task_result() will no longer be inlined, so will appear correctly in profilers like Xenon.
• added HH\\Lib\\Legacy_FIXME namespace, containing several functions emulating PHP behavior that we intend to remove from the core language. New code should never use these functions, and projects should aim to remove them over time. Currently, these include:
  • Legacy_FIXME\\increment(mixed) and decrement(mixed): reimplements the current coercion behavior of ++ and -- on null and string inputs; the coerced value is returned, not mutated in place.
  • Legacy_FIXME\\cast_for_arithmetic(mixed): match PHP’s implicit coercion for math operations on null, bools, strings (int-like, float-like, and neither), and resources.
  • lt(mixed, mixed), lte(mixed, mixed), gt(mixed, mixed), gte(mixed, mixed), cmp(mixed, mixed), eq(mixed, mixed(), neq(mixed, mixed)
  • optional_arraykey_to_int_cast_for_switch(?arraykey $value)[]: int
  • optional_num_to_int_cast_for_switch(?num $value)[]: int
  • int_cast_for_switch(mixed $value, ?arraykey $first_truthy); the second parameter is required when switching on an enum.
  • string_cast_for_basic_switch(mixed $value, ?arraykey $first_case)

These last few functions are intended to be used by replacing switch($foo) with switch(Legacy_FIXME\\string_cast_for_basic_switch($foo)), for example.

Breaking Changes

• The typechecker now detects several more forms of invalid generic types; for example, X<bool> is invalid if X is defined as X<T as arraykey>
• Class method references can no longer be coerced to other types, e.g. Foo::bar<> could previously have been coerced to vec['Foo', 'bar']. Exceptions are now raised for these conversions. On previous versions, this can be configured with the hhvm.is_compatible_cls_meth_type, hhvm.raise_cls_meth_conversion_warning, hhvm.raise_cls_meth_comparison_warning, and hhvm.is_compatible_cls_meth_type INI settings.
• ++ and -- now raise notices when the types are coerced. Ideally, avoid the coercion, otherwise migrate to the new Legacy_FIXME\\increment() and Legacy_FIXME\\decrement() functions.
• fb_intercept() has been removed; use fb_intercept2()
• removed support for a global handler in fb_intercept2() as it would not reliably trigger, could recurse, and could crash HHVM.
• hphp_debugger_attached() always returns false in repo-authoritative mode, as it could have performance implications, and is not reliable when attached in repo-authoritative mode.

Future Changes

• Built-in operators will error on the behaviors implemented by the Legacy_FIXME functions in a future release.

A security update has been released for all supported HHVM versions. Please update to one of the following versions to get the update:

• 4.80.5
• 4.102.2
• 4.113.1
• 4.114.1
• 4.115.1
• 4.116.1
• 4.117.1
• 4.118.2

4.80.6 and 4.102.3 are also released for Debian 10 Buster and Ubuntu 18.04 Bionic, updating build system compatibility with those platforms.

This security update addresses:

• CVE-2021-24036, a remote code execution vulnerability in Folly’s IOBuf class
• an issue in HHVM that could lead to specially crafted XBox request parameter data being interpreted as other RPCServer commands.

HHVM 4.118.1 is released! This release fixes an issue introduced in 4.118.0, leading to a segmentation fault when building a bytecode repository for repo-authoritative mode in some environments. Earlier releases are not affected.

HHVM 4.118 is released! This release marks the end of support for 4.112; HHVM 4.113–4.117 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• added HHI for ext_facts; when using the watchman-based autoloader, this provides information about the declarations in the current repository.

Breaking Changes

• Stringish is now sealed to StringishObject and can not be directly extended. Any class implementing __toString(): string automatically implements the StringishObject interface.

HHVM 4.117 is released! This release marks the end of support for 4.111; HHVM 4.112–4.116 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• HH\FIXME\UNSAFE_CAST can now be used as a slightly safer alternative to HH_FIXME comments.

Breaking Changes

• The Stringish interface no longer declares a __toString() method. This method is now declared only on the StringishObject interface (added in HHVM 4.115).
  • The declaration of __toString() on Stringish was misleading, since string is a subtype of Stringish but trying to call any method on a string value results in a runtime error.
• Various legacy array compatibility INI options were removed (they had no effect or didn’t work as expected since HHVM 4.103):
  • hhvm.raise_array_serialization_notices
  • hhvm.hack_arr_compat_intish_cast_notices
  • hhvm.hack_arr_compat_notices
  • hhvm.array_provenance

Future Changes

• As announced last week, in the future, the “fuzzy” comparison operators == and !=, as well as switch statements, will no longer treat values of different types as equal.
  • The INI option hhvm.notice_on_coerce_for_eq now supports a new value, 3. This enables the new behavior, i.e. comparing values of different types will return false. We recommend setting this option to 1 (raise notices) or 2 (throw exceptions) first to catch any comparisons that would be affected.

HHVM 4.116 is released! This release marks the end of support for 4.110; HHVM 4.111–4.115 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• Enum inclusion: It is no longer an error to indirectly include the same enum multiple times (example).
• It is no longer an error to use the is and as operators with varray and darray types. These types are equivalent to vec and dict since HHVM 4.103.

Breaking Changes

• Trying to convert an object to an int or float now throws an exception (previously it would raise a notice).
• After an is_array($value) check, the typechecker now more precisely refines the type of $value. This may reveal some previously hidden errors.
  • In previous HHVM versions, the .hhconfig option is_array=true can be used to enable this behavior. This option was removed in HHVM 4.116.
• Various legacy array compatibility INI options were removed (they had no effect or didn’t work as expected since HHVM 4.103):
  • hhvm.hack_arr_compat_check_compare
  • hhvm.hack_arr_compat_fb_serialize_hack_arrays_notices
  • hhvm.hack_arr_compat_is_vec_dict_notices
  • hhvm.hack_arr_compat_compact_serialize_notices
  • hhvm.hack_arr_compat_cast_marked_array_notices
  • hhvm.hack_arr_is_shape_tuple_notices
  • hhvm.hack_arr_dv_arrs

Future Changes

• In the future, the “fuzzy” comparison operators == and != will no longer treat values of different types as equal (similarly to their strict variants === and !==).
  • This will also affect switch statements where the type of the switch expression is different from any of the case expressions.
  • For easier migration, the INI option hhvm.notice_on_coerce_for_eq=1 can be used to raise a notice whenever values of different types are compared using these operators (set to 2 to throw an exception).

HHVM 4.115 is released! This release marks the end of support for 4.109; HHVM 4.110–4.114 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• A new built-in interface, StringishObject, was added. It is a subtype of Stringish that does not include strings, only objects with a __toString() method.
  • Unlike Stringish, it is therefore always safe to call __toString() after a ($value is StringishObject) check.
  • Similarly to Stringish, classes don’t have to explicitly specify that they implement StringishObject. It is automatically added to all classes that have a __toString() method.

Breaking Changes

• The INI options hhvm.repo.central.path and hhvm.repo.local.path were replaced with a single option, hhvm.repo.path (see documentation).
  • For easier migration, HHVM currently accepts either of the 3 options, and they are all equivalent. The two old options may be removed in a future release.
• Improved type inference for lambda functions that are generators (they contain yield statements). This may reveal some previously hidden errors.

Future Changes

• We expect HHVM to become more strict in some cases when a class inherits a conflicting constant declaration from a trait and a parent class/interface (examples).
  • The INI option hhvm.trait_constant_interface_behavior=1 can be used to enable the future behavior now.
• As announced last week, we expect the typechecker to start enforcing that arguments provided to the <<__Sealed(...)>> attribute are actually existing subclasses/implementations of the annotated class/interface.
  • This release adds the .hhconfig option enable_sealed_subclasses=true which can be used to enable the future behavior now.

HHVM 4.114 is released! This release marks the end of support for 4.108; HHVM 4.109–4.113 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• Fixed a bug that prevented passing dynamic-typed arguments to some Hack Standard Library functions.
• Fixed a bug where HHVM would crash when the negation (!) operator is used on some comparisons of array-typed values (e.g. !(vec[2,3,4] == vec[1,2,3])).

Future Changes

• In a future release, we expect the typechecker to start enforcing that arguments provided to the <<__Sealed(...)>> attribute are actually existing subclasses/implementations of the annotated class/interface.
  • .hhconfig option to enable this behavior should become available in the next release.

HHVM 4.113 is released! This release marks the end of support for 4.107; HHVM 4.108–4.112 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• Packages for Ubuntu 21.04 (Hirsute Hippo) are now available.

Breaking Changes

• Fixed a bug where the typechecker would sometimes incorrectly infer the type of a value when dealing with arraykey and num-typed values. This may reveal some previously undetected errors.
• The INI option hhvm.server.allow_duplicate_cookies was removed.

Slack Group

If you are interested in HHVM, you’re welcome to join our Slack group.

This replaces our IRC channel, which has been inactive for a long time.

HHVM 4.112 is released! This release marks the end of support for 4.106; HHVM 4.107–4.111 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• A new built-in method ReflectionTypeConstant::getTypeStructure() was added (it had already been available in HHVM, but previously not recognized by the typechecker).
• Type constants on this (e.g. this::T) can now be used as reified generic type parameters. Note that the type this itself is still not allowed as a reified generic type parameter.

Breaking Changes

• The typechecker now raises an error if the built-ins echo and print are used with arguments that are not int or string.
• Fixed a bug where the typechecker would not correctly enforce generic type constraints on opaque type aliases (e.g. newtype X<T as arraykey> = T;). This may reveal some previously undetected errors.

HHVM 4.111 is released! This release marks the end of support for 4.105; HHVM 4.106–4.110 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• Abstract context constants are now allowed by default (in previous HHVM versions, they can be enabled using the INI option enable_abstract_context_constants = true).
• The typechecker no longer raises an error if the ?-> operator is used on an object of a non-nullable type (these calls are safe, even if unnecessary).

Breaking Changes

• The typechecker now raises an error when the same non-abstract method is included in a class via multiple traits. These had already been runtime errors, but not always caught by the typechecker.
• The typechecker now detects more cases when a Map is used with a key of an invalid type (e.g. dynamic, null) that would previously only cause runtime errors.
• Fixed a bug where the typechecker wouldn’t detect a constructor calling a method with an uninitialized instance variable: $this->someMethod($this->uninitializedVar)

HHVM 4.110 is released! This release marks the end of support for 4.104; HHVM 4.105–4.109 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• Fixed behavior of setlocale() when called with the special values "" or "0" (#8834).
  • More details in previous announcement.
  • The default locale will now consistently be “C”.
• IDE integration will now autocomplete shape field names when calling a function with a shape-typed argument.
• The runtime no longer raises an error when JSON-serializing a method reference.
• Improved typechecker error message for a non-abstract method missing a body.

Breaking Changes

• The built-in functions preg_last_error(), json_last_error(), and json_last_error_msg() have been deleted. They have been deprecated since HHVM 4.106. Instead, use these alternatives:
  • json_decode_with_error()
  • json_encode_with_error()
  • preg_grep_with_error()
  • preg_match_all_with_error()
  • preg_match_with_error()
  • preg_replace_with_error()
  • preg_split_with_error()
• The typechecker now raises an error if an <<__EntryPoint>> function has any generic type parameters.
• If a keyset, dict, Set, or Map initializer has generic type parameter(s), the typechecker now raises an error if the key type is not arraykey or its subtype (int or string). For example, $foo = keyset<bool>[]; is an error.
• When appending to a keyset ($keyset[] = 'foo';), the typechecker now correctly enforces that the appended value is an int or string.
• The typechecker now raises an error when indexing into a Map using an index that is not an int or string. This had already been an error for other collection types.

HHVM 4.109 is released! This release marks the end of support for 4.103; HHVM 4.104–4.108 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• HHVM no longer crashes if a signal is received after calling exit()
• ext_facts, ext_watchman and the watchman-based native autoloader are now included in builds by default, building and statically linking libwatchmanclient if a dynamic version is not available in the build system.
• added HH\enable_function_coverage() and HH\collect_function_coverage(); these are intended for calculating unit test coverage only, and only function if repo-authoritative mode is not enabled, and the hhvm.enable_func_coverage ini setting is 1.
• added hhvm --check-repo; this can be used to verify that a repo-authoritative repo was built with a compatible HHVM and with compatible options. It may be useful as a debugging tool for CI/CD pipelines, but it is not a necessary step.
• added the hhvm.notice_on_coerce_for_cmp option, raising notices for cases where invalid comparisons are made between different types. This option does not control cases where there were already dedicated options, such as implicit __toString() calls.

Future Changes

• Several bugs are being fixed in setlocale(), leading to observerable changes; this affects both Hack code, and C/C++ extension code in HHVM, as HHVM replaces the libc setlocale() with a request-aware version.
  • The initial locale for each request will now be reported as "C" by setlocale(); previously, HHVM reported the empty string, leading to differing behavior:
    • C code using uselocale() would detect the "C" locale
    • C or Hack code using setlocale() would sometimes detect it as C, sometimes manually infer it from the environment, or use it as some other special locale, eg an invalid locale, or the ‘root’ locale in ICU.
  • Setting the locale to the empty string will now infer the locale from the environment. For example, if LC_ALL=en_US.UTF-8 is set, setlocale(LC_ALL, '') will set the locale to en_US.UTF-8, and this will be indicated when retrieving the locale via setlocale(). Previously:
    • C code using uselocale() would use the locale from the environment
    • C or Hack code using setlocale() would not be able to distinguish this state from the initial state
  • Overall, these bugfixes make the behavior more predicatable and closer to C/POSIX/Python behavior. Notably, the default locale of "C" differs to PHP, which defaults to using the environment locale.

Watchman-based Built-In Autoloading

Built-in autoloading is now available, but depends on the Watchman daemon being installed on your system.

Both per-repository and per-process (or global) settings are required; first, a Watchman query must be specified in REPO_ROOT/.hhvmconfig.hdf, e.g.:

Autoload {
  Query = {"expression": ["allof", ["type", "f"], ["suffix", ["anyof", "hack", "php"]], ["not",["anyof",["dirname",".hg"],["dirname",".git"],["dirname",".svn"]]]]}
}

Additionally, the following options need to be specified on the command line or in a configuration file:

• hhvm.autoload.enabled=true
• hhvm.autoload.db.path=foo/autoload-%{euid}-%{schema}.db

%{euid} and %{schema} are template placeholders:

• %{schema} is replaced with a hash which changes if your HHVM version, parser flags, or .hhvmconfig.hdf file changes. Changes to any of these factors might change the way autoloading works, and changing the hash ensures we’ll store autoloading data in a different DB.
• %{euid} is replaced with the effective UNIX user ID that HHVM’s running as. Different users on a host might be running HHVM. Including the UNIX EUID ensures that each UNIX user has a personal DB they can write to, avoiding permissions errors.

Correct configuration can be verified by:

• checking the return value of HH\Facts\enabled()
• calling class_exists() or function_exists() in your entrypoint on a definition that requires autoloading

When using the built-in autoloader, it is not necessary to initialize separate autoloaders such as the hhvm-autoload tool; for example, it is not necessary to require('vendor/autoload.hack') or to call Facebook\AutoloadMap\initialize().

We expect future versions of HHVM to:

• reduce the amount of configuration required
• continue to support Watchman, but not require it; Watchman will likely remain recommended, especially for larger projects

HHVM 4.108 is released! HHVM 4.103–4.107 remain supported, as do the 4.80 and 4.102 LTS releases.

Highlights

• The Hack Standard Library is now a built-in part of HHVM. Hack projects can now call any HSL functions without downloading and installing any extra packages.
  • This includes HSL IO, which is no longer considered experimental. Other parts of hsl-experimental are not yet included.
• Constraints (as/super) on abstract context constants are now supported.
• The HHVM runtime currently doesn’t allow using meth_caller() with a private or protected method (even within the same class hierarchy), but these runtime errors are not detected by the Hack typechecker. A new .hhconfig option, meth_caller_only_public_visibility = true, can be used to raise Hack errors in these cases. However, the plan is to support private and protected methods in meth_caller() in the future, at which point this .hhconfig option will become unnecessary.

Future Changes

• Functions in the Str\ namespace in the (now built-in) Hack Standard Library will no longer respect the system/request locale. Instead, they will default to using the POSIX (also known as C) locale.
  • In the future, we expect most of them to accept additional parameter(s) overriding the default locale and encoding, but these may not be available immediately.
  • Removing the dependency on a global locale setting will allow these functions to be considered “pure” (they can be called from other functions with any contexts, including an empty context list).

HHVM 4.107 is released! This release marks the end of support for 4.101; HHVM 4.102–4.106 remain supported, as does the 4.80 LTS release.

Highlights

• Added an hhconfig option to ban partially abstract type constants; we expect the disallow_partially_abstract_typeconst_definitions flag to be on by default in a future release. This is different to the previous disable_partially_abstact_typeconstants option, which disables the ability to override them.
• Error messages for now report generic type constraints, e.g. expected T as string instead of just expected T
• Improved error message for variadic functions where type and name aren’t specified.
• The typechecker now treats is nonnull the same as !== null; both already had special cases in type refinement, but some were exclusive to !== null.
• IDE autocompletion is now supported for XHP enum attributes.

Future Changes

• php_version(), PHP_VERSION, PHP_VERSION_ID, PHP_MAJOR_VERSION and related constants/functions will be removed, as they are misleading. If you need to detect if specific PHP5-compatible behaviors are enabled, use ini_get('hhvm.php7.foo'). The PHP5-compatible behaviors remain unsupported and are disabled by default.
• repo-authoritative mode repositories are now a custom format instead of sqlite; this should only affect deployment workflows that are explicitly examining the contents of the file.
• # comments will be used; use // or /* comments instead. #! will still be ignored if it is the first line of a file, i.e. a ‘shebang’ line, such as #!/usr/bin/env hhvm. We expect to re-use the # token for new syntax in a future release.

tl/dr: we’re doubling down on removing surprising implicit (and some explicit) coercions from the language. So far we

• are very close to having object → num conversion trigger exceptions
• have pieces in flight for the removal of coercions due to string interpolation/concatenation, mathematical operations (including bitwise), and pre/post increment/decrement
• have concrete plans for comparison operators, the (in)equality operators, and switch statements.

Context

Implicit coercions can be unintuitive in edge cases, and these edge cases can be surprisingly common - making them the second most confusing language feature, behind arrays. Even those working on the language often make mistakes, and they are frequently a source of subtle bugs.

For those who don’t know, an implicit coercion is when a value of type A gets converted to type B as part of computing the result of an operation. Probably the most common example is how 0 == false results in true courtesy of 0 being converted to false prior to the comparison, but things go straight downhill from there (hint: try comparing '0' with false and then '0' with null). We’ve determined that the time has finally come to tackle this once and for all.

So what are we going to do about it?

Well, we’ve actually already started doing something about it! Very shortly, attempting to convert an object into a number will universally throw an exception. On top of this almost finished step, we have a few portions in flight, as well as a few more not started but still very much planned.

For the following, the possible stages are

1. No Progress - Allowed by both the Type Checker and runtime. Lints may exist.
2. Enforced By Type Checker - the Type checker will report errors
3. Soft Runtime Enforcement - Violations may trigger logs via the runtime, configurable via flag.
4. Hard Runtime Enforcement - Violations will produce a runtime exception
5. New Behaviour - Following stage 4, we may decide to re-allow the operation but with a different result.

These stages are ordered such that by a certain stage, all previous stages are implied.

String Concatenation (. , .=) interpolation

Current Behaviour: int, null, bool, float, and resource will implicitly coerce to string

1
'' . true; // '1'

Future Behaviour: only int will implicitly coerce. The rest will trigger exceptions Example:

1
2
'' . true; // `InvalidOperationException` 
'one: ' . 1; // 'one: 1'

Status of rollout: Soft Runtime Enforcement

Bitwise operations (&, |, ^, ~, <<, >>) and assignment equivalents

Current Behaviour:

&, |, ^: null, bool, float, vec, dict, keyset, and resource will implicitly coerce to int. strings will implicitly coerce as well unless both operands are strings.

1
2
3
null & vec[]; // 0
keyset[1] & true; // 1
'abcd' & 'efgh'; // 'abc`'

~: floats will implicitly coerce to int

1
~1.2; // -2

<<, >>: null, bool, float, string, vec, dict, keyset, and resource will implicitly coerce to int

1
keyset[1] << true; // 2

Future Behaviour: &, |, ^: no operations will coerce. Attempting to operate on a non-int (unless both operands are strings) will trigger an exception.

1
2
3
null & vec[]; // InvalidOperationException
keyset[1] & true; // InvalidOperationException
'abcd' & 'efgh'; // 'abc`' - https://3v4l.org/CTH2o

~: no operations will coerce. Attempting to operate on a non-int or string will trigger an exception.

1
~1.2; // InvalidOperationException

<<, >>: no operations will coerce. Attempting to operate on a non-int will trigger an exception.

1
keyset[1] << true; // InvalidOperationException

Status of rollout: Soft Runtime Enforcement

Pre/post increment/decrement

Current Behaviour: Incrementing null, decrementing an empty string, and inc/dec a “numeric” string will implicitly coerce to int.

1
2
3
4
5
6
$x = null; ++$x; // 1
$x = ''; --$x; // -1
$x = ''; ++$x; // '1'
$x = '1.123'; ++$x; // 2.123
$x = '1bananas'; ++$x; // '1bananat'
$x = 'abcd'; ++$x; // 'abce'

Future Behaviour: No operations will coerce. Additionally banning incrementing an empty string for consistency. The only valid values for inc/dec are ints, floats, and non-numeric strings. Note that while inc/dec a non-numeric string is still “legal,” it’s not necessarily a great idea.

1
2
3
4
5
6
$x = null; ++$x; // InvalidOperationException
$x = ''; --$x; // InvalidOperationException
$x = ''; ++$x; // InvalidOperationException
$x = '1.123'; ++$x; // InvalidOperationException
$x = '1bananas'; ++$x; // '1bananat'
$x = 'abcd'; ++$x; // 'abce'

Status of rollout: Soft Runtime Enforcement

Mathematical operations (+, -, *, /, %, **) and assignment equivalents

Current Behaviour: null, bool, string, and resource will coerce to int / float depending on the other operand (defaulting to int for two non-num operands)

1
null + true; // 1

Future Behaviour: Operating on anything other than ints and floats will trigger an exception, with floats additionally being banned for use with %. It’s worth noting that we specifically decided to allow implicit coercions between ints and floats in this context.

1
null + true; // InvalidOperationException

Status of rollout: Soft Runtime Enforcement

Comparison operations (< ,<=, > , >=, <=>)

Current Behaviour: Attempting to list all the situations in which coercions happen and between which types would result in this post being twice as long. That should give you an idea of how much work this step will be.

1
2
3
4
5
null >= false; // true
false < new Foo(); // true
false < Foo::class; // true
true < Foo::class; // false
true > Foo::class; // false

Future Behaviour: Comparing values of two different types will throw an exception. A notable exception to this will be comparing ints and floats. In that case, comparison works as you’d expect, with the usual caveats about comparisons involving two approximately equal floats (including an approximately equal int and float).

1
2
3
4
5
null >= false; // InvalidOperationException
false < new Foo(); // InvalidOperationException
false < Foo::class; // InvalidOperationException
true < Foo::class; // InvalidOperationException
true > Foo::class; // InvalidOperationException

Status of rollout: Enforced By Type Checker

Equality operations (==, !=)

Current Behaviour: All the same combinations of types trigger coercions as with the comparison operators, but with even more situations resulting in coercions.

1
2
3
4
null == false; // true
false == new Foo(); // false
false == Foo::class; // false
true == Foo::class; // true

Future Behaviour: There will be two steps to this, going through both Hard Runtime Enforcement and then New Behaviour. First, comparing values of two different types will throw an exception. Then, comparing values of two different types will simply be false.

1
2
3
4
null == false; // InvalidOperationException then false
false == new Foo(); // InvalidOperationException then false
false == Foo::class; // InvalidOperationException then false
true == Foo::class; // InvalidOperationException then false

Status of rollout: No Progress

Switch statements

This is may be a surprise to you, but switch statements utilize == under the hood and so result in all the same coercions. As such, refer to that section for current and future behaviour.

Long Tail

In addition to the above major operational line items, we continue to discover a long tail of more minor coercions that will necessarily be tackled by this work, including things such as indexing into strings with other strings.

Next Steps

After this change, == and === will be very similar semantically, with the only major remaining differences appearing when operating on arrays and objects. This could make it confusing which one should be used. As a follow up, we will evaluate potentially removing one of the operators.

Additionally, there are a handful of above operations that don’t trigger coercions but we consider dubious nonetheless. Examples of this include bitwise operations and inc/dec on strings. As a followup, we will consider what to do about these operations.

HHVM 4.106 is released! This release marks the end of support for 4.100; HHVM 4.101–4.105 remain supported, as does the 4.80 LTS release.

Breaking Changes

• The built-in functions json_last_error(), json_last_error_msg(), and preg_last_error() are now deprecated and will be removed in a future release. Instead, use these alternatives:
  • json_decode_with_error()
  • json_encode_with_error()
  • preg_grep_with_error()
  • preg_match_all_with_error()
  • preg_match_with_error()
  • preg_replace_with_error()
  • preg_split_with_error()

Future Changes

• The deprecated built-in functions json_last_error(), json_last_error_msg(), and preg_last_error() will be removed in a future release.
• The typechecker error code for using a non-numeric value in a math operation (e.g. 2 + '3') is changing from 4110 to 4429. This doesn’t introduce any new errors, but may require HH_FIXMEs to be updated.
  • Use the .hhconfig option math_new_code = true to enable the future behavior now.

A security update has been released for all supported HHVM versions. Please update to one of the following versions to make sure you’re secure:

• 4.56.6
• 4.80.4
• 4.99.1
• 4.100.1
• 4.101.1
• 4.102.1
• 4.103.1
• 4.104.1
• 4.105.1

This security update addresses the following vulnerabilities:

• possible crash (null pointer dereference) in mailparse_rfc822_parse_addresses()
• CVE-2021-24034: “type confusion” bugs (possible memory corruption/out-of-bounds memory access) in:
  • AsyncMysqlClient methods: connect(), connectAndQuery(), connectWithOpts()
  • AsyncMysqlConnectionPool::connectWithOpts()
  • mysql_connect_with_ssl()
  • IntlCalendar methods: after(), before(), equals(), isEquivalentTo()
  • IntlTimeZone::hasSameRules()
  • XMLReader::expand()
  • various DOMDocument, DOMNode, DOMImplementation, DOMXPath methods

HHVM 4.105 is released! This release marks the end of support for 4.99; HHVM 4.100–4.104 remain supported, as does the 4.80 LTS release.

Highlights

• Rust components are now built using Rust 1.51.0
• Fixed several bugs in the new enum class feature
• Improved runtime error message when too many arguments are passed to a closure: the function is now reported as Closure$func#num() instead of __invoke()
• method overrides can now specify a more restricitve context than the original method definition
• Functions in Hack collection methods now have defined coeffects.
• hh_server’s compression model can be changed to ZSTD by setting the sharedmem_compression .hhconfig option to a ZSTD compression level; 3 is ZSTD’s default. This is essentially CPU vs memory tradeoff - large projects may wish to experiment with this option.
• interface type constants can now be overridden by implementing classes.

Breaking Changes

• Removed the undocumented <<__ConstFun>> attribute.

Future Changes

• A future release will be deprecating and later removing json_last_error(), json_last_error_msg(), and preg_last_error()
• _with_error suffixed variants of all json/preg functions have been added and should be used instead for error checking. e.g. json_encode() has json_encode_with_error() and preg_match() has preg_match_with_error()

HHVM 4.104 is released! This release marks the end of support for 4.56 (LTS) and 4.98; HHVM 4.99–4.103 remain supported, as does the 4.80 LTS release.

Note that HHVM 4.104 is not a long-term support (LTS) release as originally scheduled. Instead, HHVM 4.102 was promoted to a LTS release.

Highlights

• Various IDE integration improvements (autocomplete, go-to-definition, tooltips).

Breaking Changes

• We no longer build packages for MacOS 10.14 (Mojave).

HHVM 4.103 is released! This release marks the end of support for 4.97; HHVM 4.98–4.101 remain supported, as do the 4.56, 4.80, and 4.102 LTS releases.

Highlights

• Functions with implicit/no return are now considered a subtype of functions that return mixed or dynamic; for example, it is now possible to pass () ==> { echo "hello"; } as a (function(): mixed)
• Improved autocomplete support for enum classes
• Reduced typechecker memory usage for large classes (including small classes with many inherited members).
• Enum classes are now enabled by default.
• Added HH\EnumClassAttribute interface, allowing definition of user attributes for enum classes.
• Many builtins are now marked as pure.

Breaking Changes

• Hack arrays and legacy arrays are unified; due to the potential scope of this change, 4.102 has been made an additional out-of-schedule LTS release to allow more time to determine migration paths.
  • varray is now an alias for vec
  • darray is now an alias for dict
  • Shapes are now backed by dicts at runtime; this generally remains considered an implementation detail, but will be helpful when handling untyped data such as decoded JSON.
  • Tuples are now backed by vecs at runtime; this is also an considered an implementation detail.
• Removed runtime support for PHP-style static anonymous functions; these have been disabled by default since May 2020, and were not correctly handled by the typechecker.
• Typechecker errors are now raised for some circular definitions of class constants; this is ongoing work, and we expect more circular definitions to be detected in future versions.
• apc_prime.so support has been removed; this was an undocumented feature that would allow providing a C++ library to pre-fill APC on HHVM startup.
• A typechecker error is now raised if an XHP class declares two attributes with the same name.
• PowerPC64 support has been removed; it has been unusable for some time, and we do not have the CI infrastructure necessary to support it.

Future Changes

• HHVM still uses hh_single_compile, however the parser and emitter are also embedded, and we expect to remove the dependency on hh_single_compile and potentially remove the executable in the future. The embedded compiler can be tested with the hhvm.hack_compiler_use_compiler_pool=false INI setting.
• We expect to remove support for MacOS 10.14 (Mojave) in the near future.

HHVM 4.102 is the last release where varray and darray are treated as distinct types from vec and dict. From HHVM 4.103 on, varray becomes an alias for vec, and darray an alias for dict (in HHVM 4.101 and 4.102, the INI option hhvm.hack_arr_dv_arrs=1 can be used to enable the new behavior).

To give users more time to migrate, we are promoting HHVM 4.102 to a long-term support (LTS) release. Similarly to other LTS releases, it will be supported until superseded by two regularly scheduled LTS releases. We expect these releases to be HHVM 4.128 and 4.152, in which case, 4.102 will be supported for ~ 50 weeks.

This replaces the regularly scheduled LTS release, HHVM 4.104, which will likely be a standard release (supported for 6 weeks). However, we might add one more unscheduled LTS release between HHVM 4.102 and 4.128 if it makes the migration from varray/darray to vec/dict easier.

HHVM 4.102 is released! This release marks the end of support for 4.96; HHVM 4.97–4.101 remain supported, as do the 4.56 and 4.80 LTS releases.

Breaking Changes

• Usage of <<__Override>> is now correctly enforced on methods declared on interfaces (previously it was only enforced on methods declared in classes and traits). The typechecker will raise an error if the attribute is used on an interface method that was not declared on any of your interface’s parent interfaces.
• The typechecker now correctly raises an error if a protected method declared in a trait is called from an invalid context. Previously, there was a bug where the typechecker would allow calling the protected method from any class that used the same trait, even if it wasn’t a child or parent of the target class. Such calls would cause a runtime error but previously wouldn’t be caught by the typechecker.

Future Changes

• In the future, using any of the arithmetic operators (+, -, *, /, %, **) with values of non-numeric types (all types except int and float) will cause an exception to be thrown at runtime. All of these cases already raise typechecker errors.
  • Same rules apply to the respective assignment operators (+=, **=, etc.).
  • The INI option hhvm.notice_on_coerce_for_math=2 can be used to enable the future behavior now (set to 1 to raise a notice instead of throwing an exception).
  • Similar restrictions also apply to the increment and decrement operators ($i++, --$i). The INI option hhvm.notice_on_coerce_for_inc_dec can be used to enable the future behavior for these (set to 1 for notice, 2 for exception).

HHVM 4.101 is released! This release marks the end of support for 4.95; HHVM 4.96–4.100 remain supported, as do the 4.56 and 4.80 LTS releases.

Highlights

• ‘Variable $x is undefined, or not always defined’ errors will no longer suggest non-denotable internal variable names, such as $0splice0

Breaking Changes

• The typechecker now checks that switch($x) is exhaustive for enum classes, not just for normal enums; the runtime continues to require that either a case matches, or there is a default case.
• array_slice() no longer converts int-like string keys to ints
• hhbbc now always runs in repo-authoritative mode

Future Changes

• Hack arrays: in the next 2-8 weeks, we expect to make varray an alias for vec, and darray an alias for dict; varray and darray will no longer be distinct types to Hack arrays. This will also affect the runtime implementation of shapes and tuples, which are currently implemented with darrays and varrays respectively. You can test this behavior now with the hhvm.hack_arr_dv_arrs=1 ini setting.

HHVM 4.100 is released! This release marks the end of support for 4.94; HHVM 4.95–4.99 remain supported, as do the 4.56 and 4.80 LTS releases.

Highlights

• The typechecker now takes advantage of the guarantee that switch statements are exhaustive (this has been enforced at runtime since HHVM 4.80), i.e. that at least one branch of the switch statement is guaranteed to be executed (or an exception is thrown).
  • This allows the typechecker to e.g. correctly infer the type of any variable that is set in all branches of the switch statement, allowing some previously rejected programs to pass.

Breaking Changes

• The built-in attribute <<__Pure>> and all related attributes (__AtMostRxAsArgs, __AtMostRxAsFunc, __Cipp, __CippGlobal, __CippLocal, __MaybeMutable, __Mutable, __MutableReturn, __NonRx, __OnlyRxIfImpl, __OwnedMutable, __ReturnsVoidToRx) were removed. They have been replaced by contexts and capabilities.
• The typechecker now raises an error if the is and as operators are used with the type nothing ($x is nothing, $x as nothing).

Future Changes

• In the future, using any of the bitwise operators with values of incompatible types will cause an exception to be thrown at runtime (all of these cases already raise typechecker errors). Affected operators:
  • &, |, ^: both operands must be int or both string
  • ~ (unary): operand must not be double
  • <<, >>: both operands must be int
  • Same rules apply to the respective assignment operators (&=, <<=, etc.).
  • The INI option hhvm.notice_on_coerce_for_bit_op=2 can be used to enable the future behavior now (set to 1 to raise a notice instead of throwing an exception).

HHVM 4.99 is released! This release marks the end of support for 4.93; HHVM 4.94–4.98 remain supported, as do the 4.56 and 4.80 LTS releases.

Highlights

• IDE support (LSP) now recognizes XHP attributes, enabling features like go-to-definition and hover to peek definition.

Breaking Changes

• The typechecker now raises an error in some previously undetected cases where a class inherits multiple conflicting definitions of the same type constant. These had already been runtime errors, but previously some cases wouldn’t be caught by the typechecker.
  • See updated documentation for more details about how naming conflicts are resolved.
• The built-in classes Exception, Error, Throwable no longer have their methods marked as <<__Pure>>. This means that exceptions can no longer be thrown from other <<__Pure>> functions.
  • The affected methods are annotated with the “pure” (empty) context list, so exceptions can still be thrown from similarly annotated pure functions.

Future Changes

• In the future, we expect the return type of meth_caller to change from __SystemLib\MethCallerHelper to a native function reference type. This shouldn’t affect normal usage, but may affect edge cases like serialization. Notably, the new values cannot be stored in APC.
  • The INI option hhvm.emit_meth_caller_func_pointers=true can be used to switch to the new format now.
  • Separately, the INI option hhvm.forbid_meth_caller_apc_serialize=1 can be used to raise a warning when values in the old format are stored in APC, without switching to the new format. Setting it to 2 will throw an exception instead of the warning.
• The built-in attribute <<__Pure>> will be removed in a future release. It has been replaced by contexts and capabilities.

A security update has been released for all supported HHVM versions. Please update to one of the following versions to make sure you’re secure:

• 4.56.3 (release 4.56.4 is identical but fixes Ubuntu 16.04 and Debian 8 support)
• 4.80.2 (release 4.80.3 is identical but fixes Ubuntu 20.10 support)
• 4.93.2
• 4.94.1
• 4.95.1
• 4.96.1
• 4.97.1
• 4.98.1

This security update addresses the following vulnerabilities:

• CVE-2020-1917: out-of-bounds write (1 byte) in exif_read_data()
• CVE-2020-1918: memory disclosure vulnerability using “data:” URLs
• CVE-2020-1919: out-of-bounds heap read in substr_compare()
• CVE-2020-1921: out-of-bounds write (1 byte) in crypt()
• CVE-2021-24025: integer overflow causing out-of-bounds heap write in preg_quote()
• out-of-bounds heap read (2 bytes) in exif_read_data()

HHVM 4.98 is released! This release marks the end of support for 4.92; HHVM 4.93–4.97 remain supported, as do the 4.56 and 4.80 LTS releases.

Highlights

• Minor improvements to various typechecker error messages.

Breaking Changes

• The typechecker now correctly reports errors when a class inherits multiple conflicting definitions of the same non-abstract constant from its parent class/interfaces/traits. These had already been runtime errors, but previously wouldn’t be caught by the typechecker.

Future Changes

• We expect the built-in function inst_meth to be removed in a future release (anonymous functions or meth_caller can be used instead).
  • The .hhconfig flag disallow_inst_meth=true and the INI option hhvm.hack.lang.disallow_inst_meth=true can be used to enforce the future behavior now.
• As mentioned last week, we expect string concatenation ('hello '.$name) and interpolation ("hello $name") to become restricted to string and int values in the future.
  • This release adds the runtime (INI) option hhvm.notice_on_coerce_for_str_concat which can be used to raise a notice (if set to 1) or throw an InvalidOperationException (if set to 2) when concatenating/interpolating other types, in addition to the typechecker flag added in last week’s release.

HHVM 4.97 is released! This release marks the end of support for 4.91; HHVM 4.92–4.96 remain supported, as do the 4.56 and 4.80 LTS releases.

Highlights

• Traits can now have constants.
• Contexts of a function/method can now be accessed via reflection (ReflectionFunction::getCoeffects and ReflectionMethod::getCoeffects).
• Improved hackfmt formatting of function calls that have is/as expressions as arguments.

Breaking Changes

• <<__Rx>> and related built-in attributes (__RxShallow, __RxLocal) were removed. Use contexts and capabilities instead.
• Enums are no longer considered final (ReflectionClass::isFinal will return false if the ReflectionClass represents an enum). This is due to upcoming features, enum classes and enum inclusion.
  • The built-in attribute <<__Sealed>> can be used to add restrictions to specific enums.
• It is now a typechecker error to use meth_caller with a method that has any inout parameters. It had already been a runtime error, but previously wouldn’t be caught by the typechecker.
• The typechecker now checks XHP constructor calls (bad calls would previously result in a runtime error, but wouldn’t be caught by the typechecker). This may reveal new errors, but it should be rare, since XHP class declarations rarely override the built-in default constructor, and are usually instantiated using the standard XHP syntax instead of explicit constructor calls.

Future Changes

• We expect string concatenation ('hello '.$name) and interpolation ("hello $name") to become restricted to string and int values in the future. These two types were chosen because they’re the only types with an unambiguous string representation (compared to e.g. a bool value which could be represented as “0”, “false”, or currently “”; similarly for null; and float values can have arbitrary precision as well as special cases like NaN).
  • The .hhconfig option enable_strict_string_concat_interp=true can be used to enable the future behavior now.
  • For more details, see related discussion.

HHVM 4.96 is released! This release marks the end of support for 4.88; HHVM 4.91–4.95 remain supported, as do the 4.56 and 4.80 LTS releases.

(Note: HHVM 4.89 and 4.90 were skipped.)

Highlights

• Improved automatic inference of lambda parameter types when dealing with mixed or dynamic (examples).

Breaking Changes

• The built-in functions assert and assert_options were removed. Using them had already been a typechecker error, but previously wouldn’t fail at runtime.
• Using an arithmetic operator (+, *, etc.) on an array now throws an InvalidOperationException (which can be caught) instead of a fatal error.
• Fixed a bug that would allow a context constant with the same name to be declared twice. This may reveal new type errors.
• The INI option hhvm.forbid_dynamic_calls_to_meth_caller was renamed to hhvm.dynamic_meth_caller_level.
  • Its behavior is unchanged, it will raise a warning (if set to 1) or throw (2) when dynamic_meth_caller is called on a static method or a method not marked as <<__DynamicallyCallable>>.

Future Changes

• Using meth_caller with arguments that are not string/::class literals will become a fatal error at runtime (it is already a typechecker error).
  • The future behavior can be enabled now using the INI option hhvm.hack.lang.disallow_dynamic_meth_caller_args.
  • dynamic_meth_caller can be used with non-literal arguments, but it can only invoke methods annotated with <<__DynamicallyCallable>> (currently might not be enforced based on the value of hhvm.dynamic_meth_caller_level, as described above).

HHVM 4.95 is released! This release marks the end of support for 4.87; HHVM 4.88–4.94 remain supported, as do the 4.56 and 4.80 LTS releases.

(Note: HHVM 4.89 and 4.90 were skipped.)

Highlights

• Fixed an issue where overriding a type constant from a parent class/interface could cause a runtime error even if the code passed the typechecker (example).
• Fixed various typechecker error messages incorrectly referring to a type constant as “property”.
• The SOAP extension now supports proxy authentication (new options proxy_ssl_cert_path, proxy_ssl_key_path, proxy_ssl_ca_bundle).

Breaking Changes

• The builtin function debug_backtrace() now returns arguments (the 'args' key in the returned array) in a vec (previously varray).
• Return type annotations were added to various DateTime methods (matching what these methods already returned). This may reveal previously hidden typechecker errors.

Future Changes

• Calling a function or method “dynamically” (e.g. calling a function/method whose name is stored in a variable) will become more restricted in the future.
  • See previous announcement for more details.
  • This release adds a new builtin function dynamic_meth_caller(string $cls_name, string $meth_name) that should be used to call instance (non-static) methods dynamically.

HHVM 4.94 is released! This release marks the end of support for 4.86; HHVM 4.87–4.93 remain supported, as do the 4.56 and 4.80 LTS releases.

Additionally, 4.88.1, 4.91.1, 4.92.1, and 4.93.1 have been released, fixing a segmentation fault on machines with less than 8GB of RAM.

(Note: HHVM 4.89 and 4.90 were skipped.)

Highlights

• Fixed a regression where HHVM would segfault on startup on systems with less than 8GB of RAM; this included most TravisCI and CircleCI configurations.
• Fixed line numbers for some runtime errors being incorrectly reported as -1.
• Fixed debug_zval_dump() incorrectly reporting a refcount of 1 for uncounted or static values; these are now explicitly marked as uncounted or static.
• The error message for attempting to use first class function pointer syntax with instance methods (as opposed to static methods) now suggests meth_caller().
• first class function pointers are now supported by debugging functions such as print_r, var_dump, and = in hphpd.

Breaking Changes

• Fixed a bug that led to a typechecker error not being consistently raised when function has a parameter with a default argument followed by another parameter without a default argument.
• The runtime will now throw undefined variable exceptions instead of raising a notice.

HHVM 4.93 is released! This release marks the end of support for 4.84; HHVM 4.86–4.92 remain supported, as do the 4.56 and 4.80 LTS releases.

(Note: HHVM 4.85, 4.89 and 4.90 were skipped.)

Highlights

• New feature: Contexts and Capabilities
  • The hhconfig flags enable_coeffects_syntax, call_coeffects, local_coeffects, and the INI option hhvm.hack.lang.enable_coeffects can be used to enabled this feature in recent HHVM versions, or to disable this feature in HHVM 4.93.
• Improved typechecker handling of subtyping with generic type parameters. Some programs that were previously rejected despite being correct, now pass (example).

Breaking Changes

• Accessing an undefined property on an object now throws an UndefinedPropertyException at runtime (previously only a notice). It had already been a typechecker error.

HHVM 4.92 is released! This release marks the end of support for 4.83; HHVM 4.84–4.91 remain supported, as do the 4.56 and 4.80 LTS releases.

(Note: HHVM 4.85, 4.89 and 4.90 were skipped.)

Highlights

• If a class A is a supertype of class/interface B via require extends, it is now able to call its’ own private methods on instances of B.
• Replaced sometimes-confusing “expected dynamic, got nonnull” with clearer “expected dynamic, got mixed”. While nonnull was technically accurate (as mixed is ?nonnull), some users misinterpreted the error as meaning that null was expected, or still consider mixed values to be mixed after a null check.

Breaking Changes

• Corrected error line number for reified generic errors; FIXME comments may need to be moved.
• The APCIterator class has been removed from the runtime, as it has generally not been kept up to date or correct, and was not exposed to the typechecker.
• apc_cache_info() now correctly returns an uncounted_entries key instead of uncounted_entires.
• Calling methods on dynamic values requires that all values are coercible to dynamic, and the return type will be dynamic.
• it is now a syntax error to declare a function as async without an Awaitable return type; previously this was separately checked by the type checker and the bytecode emitter, and the typechecker did not detect invalid async lambdas.

HHVM 4.91 is released! This release marks the end of support for 4.82; HHVM 4.83–4.88 remain supported, as do the 4.56 and 4.80 LTS releases.

(Note: HHVM 4.85, 4.89 and 4.90 were skipped.)

Highlights

• Improved typechecker handling of generic type parameters with multiple bounds. Some programs that were previously rejected despite being correct, now pass (example).
• Improved error message when getNames() is called on an enum with duplicate values.
• hackfmt now ignores non-Hack files instead of printing unhelpful error messages.
• curl_setopt() now allows passing in keys and certificates as strings if HHVM is built with libcurl >= 7.71.0. New options:
  • CURLOPT_SSLCERT_BLOB
  • CURLOPT_SSLKEY_BLOB
  • CURLOPT_PROXY_SSLCERT_BLOB
  • CURLOPT_PROXY_SSLKEY_BLOB
  • CURLOPT_ISSUERCERT_BLOB
  • CURLOPT_PROXY_ISSUERCERT_BLOB
• Optimized various ReflectionClass methods.
• Fixed a bug where number_format and json_decode could allocate large amounts of memory before checking the configured request memory limit.
• Fixed a bug where casting a string to int would behave inconsistently for strings containing the minimum int value with trailing whitespace ("-9223372036854775808 ").
• For developers working on Hack: The AST definition now contains a description and example for every type of AST node.

Breaking Changes

• The INI option hhvm.forbid_division_by_zero was removed. Division by zero now always raises an exception (this had already been the default behavior).
• The INI option hhvm.error_handling.no_infinite_recursion_detection was removed. Comparing objects with cyclical references now always raises an error (this had already been the default behavior).

Future Changes

• We are planning to make implicit coercions between different types more restrictive. A detailed proposal is available for discussion.

HHVM 4.88 is released! HHVM 4.82–4.87 remain supported, as do the 4.56 and 4.80 LTS releases.

We intend to skip 4.89 and 4.90 due to the holiday season; support for 4.82 and 4.83 will be extended until the release of 4.91 and 4.92 respectively.

Highlights

• Error messages for parse errors now include file name and line number again.

Breaking Changes

• Unrecoverable fatals such as parse errors no longer throw, so are no longer catchable. If you are using try/catch around require() (e.g. to attempt to find an autoloader), HH\could_include() is a useful replacement.
• We are no longer building for Ubuntu 19.10 ‘Eoan Ermine’, as we are no longer able to fetch the dependencies from upstream repositories. Ubuntu 19.10 reached end of life on the 17th of July, 2020.

HHVM 4.87 is released! HHVM 4.81–4.86 remain supported, as do the 4.56 and 4.80 LTS releases.

Highlights

• Packages for Ubuntu 20.10 are now available.
• The built-in functions apc_add and apc_store now take a 4th, optional argument. If this argument is provided, then the value stored in APC will be evicted if it’s not accessed for the specified number of seconds (even if the TTL specified in the previous argument hasn’t been reached yet).
• Improved various typechecker error messages.

Breaking Changes

• The .hhconfig option disallow_goto was removed—it is no longer possible to enable goto statements. It had been true by default in all recent HHVM versions.
• Indexing into a string using a non-arraykey value (not int or string) now causes an InvalidArgumentException to be thrown at runtime. String indexes like '42' stay supported for historical reasons, but generally shouldn’t be used. Using any non-int value, including strings, had already been a typechecker error.

Future Changes

• ArrayIterator and all the collections’ iterators (VectorIterator, MapIterator, etc.) are deprecated. Most use cases can be replaced by foreach loops, which HHVM can also optimize in the JIT. For the remaining cases, the current implementation can be replicated in pure Hack code.
  • There are a few behaviors, like “casting to array” and serialization, where the runtime treats these classes specially; those won’t be supported going forward.

HHVM 4.86 is released! This release marks the end of support for 4.79; HHVM 4.80–4.84 remain supported (4.85 was skipped), as does the 4.56 LTS release.

Breaking Changes

• The built-in function \preg_last_error may now return a new value, \PREG_BAD_REGEX_ERROR. Various \preg_... functions use this error code when called with an invalid regular expression (previously, they would return false without setting an error code).
• If an async function is declared with a non-Awaitable return type, the typechecker now raises an error at the position of the return type (previously, it would raise an error at the position of the function name). This doesn’t introduce any new errors but may require some HH_FIXMEs to be moved.

Future Changes

• Calling a function or method “dynamically” (e.g. calling a function/method whose name is stored in a variable) will become more restricted in the future.
  • The function/method must have the <<__DynamicallyCallable>> attribute.
  • The reference to the function/method to be called must be created using \HH\dynamic_fun($function_name) or \HH\dynamic_class_meth($class_name, $method_name) (a way to dynamically call non-static methods is in the works).
  • To enable the future behavior now, set the INI options hhvm.forbid_dynamic_calls_to_func, hhvm.forbid_dynamic_calls_to_cls_meth and/or hhvm.forbid_dynamic_calls_to_inst_meth to:
    • 0 – Do nothing
    • 1 – Warn if target is not annotated
    • 2 – Throw exception if target is not annotated; warn if dynamic callsite is using a raw string or array
    • 3 – Throw exception

HHVM 4.84 is released! This release marks the end of support for 4.78; HHVM 4.79–4.82 remain supported, as does the 4.56 LTS release. This primarily contains internal improvements for performance, maintainability, and preparation for future work.

We will not be releasing 4.85 next week due to US holidays; we expect the next release to be 4.86, during the week of 2020-11-30.

Highlights

• Fixed propagation of reified generics in class B<T> extends A<T> when A’s T parameter is reified, but B’s is not.

Future Changes

• Indexing into a string with an index that is not an arraykey will throw an InvalidArgumentException; currently, it emits a String offset cast occurred notice.

A security update has been released for all supported HHVM versions. Please update to one of the following versions to make sure you’re secure:

• 4.56.2
• 4.78.1
• 4.79.1
• 4.80.1
• 4.81.1
• 4.82.1
• 4.83.1

This security update addresses the following vulnerabilities:

• dump-static-strings (CVE-2019-3555) and dump-pcre-cache (CVE-2019-3556) admin endpoints can write to any file the webserver has access to
• out of bounds read in crypt()
• light-process.cpp not dropping privileges correctly
• integer overflow in gdImageCreate()
• null pointer dereference in XMLReader::expand()
• buffer overflow in ldap_escape() (CVE-2020-1916)

HHVM 4.83 is released! This release marks the end of support for 4.77; HHVM 4.78–4.82 remain supported, as does the 4.56 LTS release.

Breaking Changes

• Attributes used on lambda functions must now be defined, similarly to attributes used in any other position. To allow an attribute to be used on lambda functions, its definition must implement the interface \HH\LambdaAttribute.
• The option hhvm.hack.lang.enable_first_class_function_pointers was removed. The new function reference syntax is now always enabled.
• The option hhvm.emit_cls_meth_pointers is now enabled by default. It causes the built-in function class_meth() to return values in the same format as the new function reference syntax, which should make migrating easier.
  • For easier migration, the additional option hhvm.is_compatible_cls_meth_type = 1 can be used to allow both formats to be considered valid.

Future Changes

• The built-in functions fun() and class_meth() will be removed in a future release. Use the new function reference syntax instead.
  • The INI option hhvm.hack.lang.disallow_fun_and_cls_meth_pseudo_funcs = 1 and .hhconfig option disallow_fun_and_cls_meth_pseudo_funcs = true can be used to disable these functions in the current HHVM release.

HHVM 4.82 is released! This release marks the end of support for 4.76; HHVM 4.77–4.81 remain supported, as does the 4.56 LTS release.

Highlights

• AsyncMysqlQueryResults has the new method dictRowsTyped(): vec<dict<string, arraykey>>.
• Improved several typechecker error messages for incompatible method overrides, e.g. when an override has more mandatory arguments.

Breaking Changes

• array_fill_keys() will now throw an InvalidArgumentException if the first argument is not a Container; in previous versions, HHVM would return false. With this change, array_fill_keys() now only returns darrays.
• improved correctness when type constants are accessed via inferred union or intersection types. This can both lead to fewer incorrect type checker errors, but also additional correct type checker errors.

HHVM 4.81 is released! This release marks the end of support for 4.75; HHVM 4.76–4.80 remain supported, as does the 4.56 LTS release.

Highlights

• A new built-in type AnyArray was added, representing the parent type of all containers that are values (vec, dict, keyset, varray, darray; does not include containers with reference semantics like Vector). It is a subtype of KeyedContainer.

Breaking Changes

• The INI option hhvm.hack_arr_dv_arr_var_dump was removed. var_dump will now always output varray or darray instead of array.

Future Changes

• Similarly to var_dump, var_export will also start distinguishing between varray and darray.
  • Use the INI option hhvm.hack_arr_dv_arr_var_export=1 to enable this behavior now.
• Support for # comments will be removed in a future release. Use // or /* instead.
  • Shebang at the beginning of a Hack file will stay supported.

HHVM 4.80 is released! This release has long term support, so:

• this release will be supported for approximately 48 weeks
• the next LTS will be released in approximately 24 weeks
• HHVM 4.56 (LTS) and HHVM 4.75–4.79 remain supported.
• support has ended for HHVM 4.32 (LTS)

Highlights

• The bytecode cache can now store SystemLib units; this can lead to a better experience if HHVM is executed multiple times.
• Clearer error messages for unresolved subtypes of mixed; prior versions can refer to the null or nonnull subtypes of mixed, which are more specific, but can be confusing.
• Clearer error messages for variance mismatches: errors now say a type argument “only allows supertypes (it is contravariant”) or “must match exactly (it is invariant)”.
• Fixed a caching bug when a source file appears to be modified, but the content (or bytecode) is unchanged, for example, by using touch; in prior versions, this leads to immediately exiting earlier, however the metadata should be updated to reflect the new modification time.

Breaking Changes

• A typechecker error is now raised if the __LSB or __MemoizeLSB attributes are used in a final class. If this is raised, fix by removing the __LSB attribute, and replacing __MemoizeLSB with __Memoize.
• Switch statements now throw if no case or default matches.
• for loop conditions no longer permit comma-separated expressions. In prior versions, the behavior could be surprising - for example, in for(;foo(), bar();) {}, the return value of foo() is ignored. Commas are still permitted in other positions other positions, e.g. for ($i = 0, $j = 0; some_func($i, $j); ++$i, $++j).

Future Changes

• The following runtime type warnings will be changed to raise errors in a future release. Initially, this will be done by changing the INI setting from 1 (warn) to 2 (error), and we then expect to remove the options entirely. Attempting to recover from these errors may lead to additional irrecoverable errors.
  • Upper bounds of generics: hhvm.enforce_generics_ub
  • Property type hints: hhvm.check_prop_type_hints

HHVM 4.79 is released! This release marks the end of support for 4.73; HHVM 4.74–4.78 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• Introducing new function reference syntax. See updated guide. For example:
  • fun('foo') becomes foo<>
  • class_meth(Foo::class, 'bar') becomes Foo::bar<>

Breaking Changes

• HHVM now raises a notice when a method is called with incorrect case (e.g. $obj->Foo() instead of $obj->foo()). The typechecker had already been raising errors in all such cases. In the future, we expect these notices to become runtime errors.
  • the notices can be temporarily disabled using the INI option hhvm.raise_on_case_insensitive_lookup_v2=false
• The typechecker now raises an error if new self(...) or new parent(...) is used inside a class with reified generic type parameters.
• The typechecker now raises an error when trying to pass a dynamic-typed value where an enforceable reified generic type is expected.
• Some typechecker errors were moved to a more appropriate location. This doesn’t introduce any new errors, but may require HH_FIXMEs to be moved. This includes:
  • calling a function with the wrong number of arguments (now an error at the point of the call, instead of the function declaration)
  • passing a non-reified generic type parameter where a reified one is expected

Future Changes

• The built-in functions fun and class_meth will be removed in a future HHVM release, in favor of the new function reference syntax.
• We expect method names to become case sensitive soon (currently a typechecker error but only a notice at runtime, see above).

HHVM 4.78 is released! This release marks the end of support for 4.72; HHVM 4.73–4.77 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• The (class|function|interface|trait)_exists functions are now more optimized in repo-authoritative mode. This takes advantage of the fact that all HHBBC definitions are now unique and persistent.
• Improved the typechecker error for invalid (string) casts.
• var_dump() now distinguishes between varrays and darrays by default, instead of reporting both as array.

Breaking Changes

• is shape(...) requires a darray, and is tuple(...) requires a varray; is checks with reified generics are now consistent with this when the generic is a shape or tuple. Previously, reified generics were more permissive.
• require() and related functions no longer support URIs, e.g. file://foo.hack.
• All special-casing for array has been removed from the parser. It is now parsed as a name token, like user-defined types.

Future Changes

• calling array_fill_keys() will require that $keys is a Container<Tk as arraykey>; this will allow specifying a darray<Tk, Tv> return type. Currently, it will return null if $keys is not a Container.

HHVM 4.77 is released! This release marks the end of support for 4.71; HHVM 4.72–4.76 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• Removed redundant typechecker error 4164 (“Properties cannot be declared final”). The same issue is already reported as a parsing error (1002).
• Improved IDE support: The “rename” operation now also supports type aliases.

Breaking Changes

• The Xbox extension no longer supports inter-process communication (local or remote). It can still be used for in-process parallelism (xbox_task_* functions). Removed built-in functions:
  • xbox_send_message
  • xbox_post_message
  • xbox_get_thread_timeout
  • xbox_set_thread_timeout
  • xbox_schedule_thread_reset
  • xbox_get_thread_time
• A constant can no longer be used as a shape key if its type is an opaque type alias (a newtype not from the same file). This makes it more consistent with how opaque type aliases can be used in other contexts.

HHVM 4.76 is released! This release marks the end of support for 4.69; HHVM 4.71–4.75 remain supported (4.70 was skipped), as do the 4.32 and 4.56 LTS releases.

Highlights

• The typechecker now allows method calls on generic types with multiple upper bounds, as long as the method call is valid for all of them (example). Previously, it was an error if the method declarations weren’t identical on all of the upper bound types.
• The typechecker now more accurately tracks the types of all local variables when dealing with nested try/catch/finally blocks (examples). This allows some programs to typecheck that previously would have failed.

Breaking Changes

• $GLOBALS was removed. Global variables can still be accessed using the following functions:
  • HH\global_get
  • HH\global_isset
  • HH\global_key_exists
  • HH\global_set
  • HH\global_unset
• The typechecker now reports an error if a trait with any final methods is included multiple times in the same class (this can happen e.g. if the trait is used from a class as well as its parent class). Previously, this caused a runtime error but wasn’t caught by the typechecker.
• Fixed some loopholes that allowed assigning a value to a variable named $this. In almost all cases, it had already been banned by both the typechecker and the runtime, but there were some remaining edge cases:
  • catch (Exception $this)
  • calling a function with inout $this as an argument
  • unset($this)
• ?enum {...} is no longer a valid XHP attribute type. Use enum {...} instead, which is equivalent (XHP attributes are nullable unless declared as @required).
• Using $$ (special variable inside a pipe expression) as an inout argument now raises a fatal error at runtime. It had already been a typechecker error.

HHVM 4.75 is released! This release marks the end of support for 4.68; HHVM 4.69–4.74 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• Continued improvements to the recently added highlighted error formatter.
• The environment variable FORCE_ERROR_COLOR can be used to force hh_client to output color escape sequences even if the output is not a terminal, e.g. to save the output into a file that can be printed to a compatible terminal later.

Breaking Changes

• is_array() is now equivalent to HH\is_any_array() (previously equivalent to HH\is_php_array()). We expect this to be the last step before is_array() is removed completely (it had already been removed from the typechecker since HHVM 4.71, but for now is still available at runtime), so please migrate to HH\is_any_array() (preserving the new behavior), HH\is_php_array() (preserving the old behavior), or another of the alternatives listed in HHVM 4.71 release notes.
• The built-in functions call_user_func() and call_user_func_array() were deprecated. Using them raises a typechecker error, but for now still works at runtime (we expect runtime support to also be removed soon).
  • Use $callable() instead, where $callable is an anonymous function, or the return value from fun(), class_meth(), inst_meth() or meth_caller(). All of these are understood by the typechecker, so the change may reveal previously hidden errors.
  • Using a string as $callable raises a typechecker error, but for now still works at runtime. However, we expect it to stop working soon, as the native “function pointer” types returned by the functions above will become the only valid representations of functions and methods.
• The INI option hhvm.emit_func_pointers has been removed, fun() now always returns a native “function pointer” type instead of a string.
  • hhvm.emit_cls_meth_pointers and other related flags are also expected to be removed soon.
• The type of exception thrown when using a string key (instead of int) to index into a varray changed from OutOfBoundsException to InvalidArgumentException.
  • In previous HHVM versions, the hhvm.hack_arr_compat_notices INI option can be used to raise a notice (in addition to the OutOfBoundsException) in these cases.
• Changed behavior of the > and >= operators on varrays to be consistent with vecs. This only affects rare cases such as comparing arrays of objects or NAN values.
  • Both before and after this change, comparing any array types using these operators raises a typechecker error and often has surprising and inconsistent results at runtime, so it should be avoided.

Future Changes

• is_array() will be removed completely.
• Support for using strings or tuples to represent functions and methods will be removed in a future release. They are being replaced by a native “function pointer” type.
  • Using fun() or another option listed above guarantees that the return value will be compatible with the specific HHVM version being used, no matter which type it uses to represent functions.

HHVM 4.74 is released! This release marks the end of support for 4.67; HHVM 4.68–4.73 remain supported, as do the 4.32 and 4.56 LTS releases.

Breaking Changes

• Previous versions of the typechecker checked for overridden final methods in two places; now this is consistently checked once in the typechecking phase, which can result in changed error codes.
• Single-quoted string shape keys that contain escape sequences (backslashes) are now handled the same way as other single-quoted strings. Previous versions would incorrectly include the backslash in the key.
• The typechecker now verifies method where constraints are well-formed; method generic constraints (e.g. public function foo<T as Bar>()) were already verified in this way.

HHVM 4.73 is released! This release marks the end of support for 4.66; HHVM 4.67–4.72 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• Support for using XHP classes (elements) with namespaces is now enabled by default. This comes with many related XHP changes.
  • See separate blog post for a detailed list of changes. Most important breaking changes are also listed below.
  • See setup instructions for how to enable this in previous HHVM versions or disable it in HHVM 4.73.
  • These changes are incompatible with xhp-lib v3. Hack projects must upgrade to xhp-lib v4 to use XHP with namespaces.
  • Automated migrations for all language changes and from xhp-lib v3 to v4 are available in HHAST 4.64.6 or newer.
• Various improvements to the new hh_client error formatter.

Breaking Changes

• Related to XHP namespace support:
  • Syntax changed from class :foo to xhp class foo.
  • Name mangling is no longer used, xhp class foo now declares a class named foo, not xhp_foo. This can cause new naming conflicts, and can also cause issues anywhere the old mangled class names are passed around as strings.
  • - is no longer allowed inside XHP class names.
  • : is now a namespace separator, class foo:bar declares a class named bar in the foo sub-namespace of the current namespace (namespace\foo\bar).
  • The category %foo, %bar syntax is no longer supported.
  • The children (...) syntax is not supported by xhp-lib v4, we recommend disabling it in the typechecker by adding disable_xhp_children_declarations=true to .hhconfig.
• The built-in functions current(), key(), reset() and end() were removed. This continues the previously announced removal of arrays’ built-in “internal iterators”.
• Using the built-in function \HH\global_keys() now raises a typechecker error. It had already been removed from the runtime, but was incorrectly still accepted by the typechecker.
• Declaring a non-static variable (property) in an abstract final class is now a typechecker error. It had already been a runtime error.
• The INI option hhvm.dynamic_invoke_functions has been removed. This option allowed specifying a list of functions that could be used with fb_intercept or fb_rename_function in repo-authoritative mode. It’s no longer possible to control this per-function, but it can still be controlled globally using hhvm.jit_enable_rename_function.
• The INI option hhvm.use_repo_autoload_map has been removed (preserving default true). The built-in autoload map is now always used in repo-authoritative mode.

Today we are releasing significant changes to XHP - in Hack, HHVM, and in the class/function library; XHP now fully supports namespaces - both using XHP from other namespaces, and defining XHP components in namespaces.

XHP v4 includes several changes to:

• directly support namespaces.
• remove features that would introduce parser ambiguities when combined with namespace support.
• remove features that surprise users and can be expressed in other, more consistent ways.
• make a clear distinction between ‘core’ and HTML functionality, to enable broader use of XHP in new contexts.
• be consistent with other modern Hack libraries, especially the HSL.

We expect future development of XHP to be focused on making XHP more consistent with the rest of Hack, especially from a type system perspective.

Overview

• XHP classes are now declared as xhp class foo {} instead of class :foo
• in XHP contexts, the : token acts as a namespace separator; foo:bar is equivalent to foo\bar (and namespace\foo\bar), and :foo:bar is equivalent to \foo\bar.
• children declarations have been replaced with a trait and are no longer a language feature
• categories have been replaced with interfaces
• the XHP class and function library is now namespaced
• renderAsync() replaces asyncRender() and render()

XHP v3 Example

1
2
3
4
5
6
7
8
class :foo:bar extends :x:element {
  category %flow;
  children (:div, :code*);

  protected function render(): void {
    return <x:frag>{$this->getChildren());
  }
}

XHP v4 Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
namespace foo;

use namespace Facebook\XHP\Core as x;
use namespace Facebook\XHP\ChildValidation as XHPChild;
use type Facebook\XHP\HTML\{div, code};

xhp class bar extends x\element
implements \Facebook\XHP\HTML\Category\Flow {
  use XHPChild\Validation;

  protected static function getChildrenDeclaration(): XHPChild\Constraint {
    return XHPChild\any_of(
      XHPChild\of_type<div>(),
      XHPChild\at_least_one_of(XHPChild\of_type<code>()),
    );
  }

  protected async function renderAsync(): Awaitable<XHPRoot> {
    return <x:frag>{$this->getChildren()}</x:frag>;
    // alternatively:
    return
      <:Facebook:XHP:Core:frag>
        {$this->getChildren()}
      </:Facebook:XHP:Core:frag>;
  }
}

Migration

Automated migrations for all language changes, and for most classes and functions renamed in xhp-lib v4, are available in HHAST 4.64.6 or newer (some also available in older HHAST versions).

• hhast-migrate --add-xhp-children-declaration-method adds the ChildValidation trait and getChildrenDeclaration() method based on existing children declarations.
• hhast-migrate --remove-xhp-child-declarations (run after the above migration) will remove the now redundant children declarations.
• hhast-migrate --demangle-xhp-class-names replaces - in XHP class names with _
• hhast-migrate --xhp-class-modifier migrates class :foo:bar to xhp class foo:bar
• hhast-migrate --xhp-lib-v3-to-v4 migrates most class and function names changed in xhp-lib v4, adds the necessary use clauses (this includes all HTML tags)

In rare cases, these migrations can result in typechecker errors (e.g. naming conflicts due to the removal of XHP class name mangling) or hhast-lint errors (e.g. redundant use clauses) which need to be fixed manually.

Additional changes that may require manual migration:

• Consider moving any XHP class declarations from the global namespace into namespaces consistent with the rest of your codebase.
• Optionally change xhp class foo:bar:baz { ... } to the equivalent namespace foo\bar; xhp class baz { ... } based on your preferred style.
• Replace category declarations with interfaces (new or existing; common ones can be found in the Facebook\XHP\HTML\Category namespace).
• Calls to $xhp->toString() need to be updated to $xhp->toStringAsync().
• Calls to $xhp->getChildren(...), $xhp->getFirstChild(...) and other methods that had their argument removed need to be updated to $xhp->getChildrenOfType<...>(), $xhp->getFirstChildOfType<...>(), etc.
• Most deprecated features (e.g. attribute clobbering, forceAttribute) are not handled by the automated migrations, we recommend replacing them with equivalent or similar non-deprecated features.

Details

Language changes

A more formal description of these changes is also available.

Syntax

Previously, XHP classes were declared with a leading colon, e.g.

class :foo:bar {}

XHP classes are now declared with the following syntax:

namespace foo;

xhp class bar {}

This new syntax avoids ambiguities that would otherwise be introduced by the addition of namespace support.

xhp class foo:bar {} is also permitted - it is intended to be used:

• by existing codebases, as a migration aid
• as a stylistic preference by codebases that choose to minimize use of namespaces

Naming

Previously, XHP class names were ‘mangled’ into a form that meets the usual restrictions for Hack class names; for example, class :foo:bar-baz {} actually defined the class xhp_foo__bar_baz.

XHP class names are no longer mangled: xhp class foo defines the class foo, and xhp class foo:bar defines the class foo\bar; this may cause problems if you are storing or otherwise interacting with classname<T> of XHP classes, or storing serialized instances of XHP classes.

This also means that XHP class names must now be valid Hack XHP class names; the most significant effect is that the - character is no longer permitted in XHP class names.

Colons in XHP class types

Colons are now a namespace separator (largely equivalent to \), but are only permitted in some contexts:

• in XHP-specific language constructs, such as xhp class foo:bar, <foo:bar>
• when fully-qualified, in other contexts where qualified names are permitted - for example, function foo(:bar:baz $_) is permitted, but function foo(bar:baz $_) is not permitted

\ is not permitted in XHP constructor calls (e.g. <foo\bar> is an error), or XHP class declaration names (e.g. xhp class foo\bar). It is permitted in parent class references, e.g. xhp class foo extends bar\baz {}.

Like \, : can be used to indicate that a name is fully qualified; for example, foo\bar and foo:bar both refer to namespace\foo\bar (unless there is a relevant use statement), and \foo\bar and :foo:bar both always refer to \foo\bar. Similarly, <foo:bar /> is a reference to namespace\foo\bar, and <:foo:bar /> is now permitted as a reference to \foo\bar.

There are several situations where both \ and : are permitted; we recommend that codebases decide on a consistent style; for example, code bases may wish to ban:

• using : for anything that is not an XHP class
• using \ in XHP-specific contexts
• declaring elements in sub-namespaces (e.g. permit namespace foo { xhp class bar {} }, but ban xhp class foo:bar {})

Category Declarations

The category %foo, %bar syntax is no longer supported - we recommend using interfaces instead.

They were largely equivalent to interfaces, but without typechecker support; this both increased complexity, and users reasonably assume there was typechecker support.

Child Declarations

The children (...) syntax is no longer supported; XHP-Lib v4 supports a variant of the approach introduced in v3.1, however functions have been renamed to lower_camel_case for consistency with other common Hack libraries.

Core APIs

There is now a clean separation between core APIs and HTML-specific APIs; we hope this will lead to more diverse uses of XHP in the future.

Core XHP classes and functions are now in the Facebook\XHP\Core namespace; child validation has been moved to Facebook\XHP\ChildValidation, and is no longer considered a core feature.

This also includes core elements and base classes; in particular:

• :x:composable-element is now Facebook\XHP\Core\node
• :x:element is now Facebook\XHP\Core\element, and :x:frag is now Facebook\XHP\Core\frag

HTML Elements

These are now all in the Facebook\XHP\HTML namespace; they can be used:

• fully-qualified, e.g. <:facebook:xhp:html:div>
• with a use type, e.g. use type Facebook\XHP\HTML\{code, div}; $_ = <div />
• with a use namespace, e.g. use namespace Facebook\XHP\HTML as h; $_ = <h:div />

Additionally:

• the categories have been updated to match the specification; in some cases, this has meant removing categories, which may mean markup must be restructured to be valid
• the categories are now interfaces in the Facebook\XHP\HTML\Category namespace

Other changes

• HasXHPAttributeClobbering_DEPRECATED has been removed; use attribute splat instead
• UnsafeAttributeValue has been renamed to UnsafeAttributeValue_DEPRECATED as it bypassing the type system by design, and will need to be removed in a future release
• forceAttribute() has been renamed to forceAttribute_DEPRECATED() as it bypassing the type system by design, and will need to be removed in a future release
• it is now an error to render an element twice, or to mutate it after it has been rendered
• asyncRender() has been renamed to renderAsync(), for consistency with other popular Hack projects and the HSL
• render() has been removed; always use renderAsync() instead.
• the XHPRoot interface and :xhp classes have been removed as unnecessary; use Facebook\XHP\Core\Node or XHPChild instead.
• removed selectors from getFirstChild() and related functions; added getFirstChildOfType<T as XHPChild>() with improved typechecker support. An interface can be specified to replace previous category specifications.

Thanks

It has been a very long path to get here, and much more involved than we expected. I’d like to thank our friends at Slack - especially Johan Oskarsson - who made this possible, and also Lexidor Digital whose contributions to type safety are greatly appreciated.

HHVM 4.72 is released! This release marks the end of support for 4.65; HHVM 4.66–4.71 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• Various varray and darray runtime errors (e.g. out of bounds access) now have clearer error messages, and are consistent with the equivalent vec/ dict error messages.
• If hhvm.hack_arr_compat_notices is enabled, a notice is now raised when a varray is indexed by a string.
• Typechecker errors for uninitialized properties now suggest the specific nullable type and property (e.g. ?int $myPropertyName) instead of the placeholder ?YourTypeHere.
• It is now possible to enable unstable features on a per-file basis for experimentation - see below for details.

Breaking Changes

• <<__Override>> attributes were not checked on abstract classes; this bug has now been fixed, so type errors will now be raised if a method on an abstract class is marked with this attribute, but it is in fact not overriding a parent definition.
• it is now a typechecker error to use class_meth(), fun(), meth_caller() etc to create a reference to functions or methods with reified generics, as any call to such a reference is an error.
• references to abstract methods have been similarly banned.
• class_meth(__CLASS__) in non-final classes is now a typechecker error. This can be resolved by:
  • making the class final.
  • replacing with the more-explicit static::class or self::class.

Enabling Unstable Features

Unstable features are likely to be completely rewritten, restricted to builtins, or removed entirely, and any issues will generally be considered very low priority.

Experimental features can be enabled by:

• adding allow_unstable_features=true to /etc/hh.conf or /usr/local/etc/hh.conf (location may vary depending on your platform and package source).
• adding hhvm.hack.lang.allow_unstable_features=true to your HHVM configuration
• adding a file-level attribute at every usage, indicating which specific experimental feature is being used.

For example:

1
2
3
4
5
6
7
8
9
<<file:__EnableUnstableFeatures('union_intersection_type_hints')>>

function use_unstable_feature((int | bool) $x): int {
  if ($x is bool) {
    return $x ? 1 : 0;
  } else {
    return $x as int;
  }
}

Experimental features should not be used in production code.

HHVM 4.71 is released! This release marks the end of support for 4.64; HHVM 4.65–4.69 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• The console output of hh_client has been significantly improved, with better color highlighting, error messages shown in a better order, smarter handling of overlapping positions, added surrounding lines of code, and other improvements.
  • hh_client --error-format ... can be used to switch between the different output formats.
• Building HHVM from source should be easier now, and the source packages are much smaller, due to the removal of multiple large “submodules” like Boost and MySQL (these are now downloaded as needed, e.g. if the system version is too old).

Breaking Changes

• The built-in function is_array() was removed from the typechecker and will soon be removed completely. Instead, use one of the following:
  • HH\is_php_array() accepts only legacy arrays (varray, darray). This is equivalent to is_array(), so it guarantees no change in behavior, but makes it harder to migrate from legacy arrays to Hack arrays in the future.
  • HH\is_any_array() accepts legacy array types (varray, darray) as well as Hack arrays (vec, dict, keyset). This makes any future migration from legacy arrays to Hack arrays safer, but it is not equivalent to is_array(), so the change may need some manual review and testing.
  • HH\is_vec_or_varray() and HH\is_dict_or_darray() allow you to test for vec/dict-like behavior, while still making it safe to migrate from legacy arrays to Hack arrays in the future.
  • For code that doesn’t care about the exact container type, consider using a more generic interface, e.g. $var is Container<_> or $var is KeyedContainer<_, _>.
• HHVM no longer parses PHP files (files with the .php extension starting with <?php instead of <?hh). The typechecker ignores them (making it possible for Hack and PHP code to live in the same repository), while the runtime and some other commands (e.g. hh_parse) will raise errors when trying to process them.
  • HHVM hasn’t supported PHP since HHVM 4.0, but until now the behavior for PHP files was inconsistent and could depend on whether they happened to contain valid Hack code or not.
• The typechecker will now complain about incorrect mode (e.g. <?hh // struct) even when the --disable-modes flag is used.
• Fixed a bug where the typechecker would not detect a missing generic type parameter in a var-args function declaration (class A<T> {}, function test(A ...$a): void {}). This may reveal previously undetected errors.
• Fixed a bug where isset would return an incorrect value when used with dict or keyset elements (isset($dict['key'])).

Future Changes

• The is_array() function will also be removed from the runtime (currently, it has only been removed from the typechecker).

We have decided to skip this week’s regular release, HHVM 4.70.

There’s been a regression that prevented us from publishing the release earlier this week, which we are still working on fixing. Instead of shipping the release only a few days before the next one, we decided to skip it.

Support for HHVM 4.64 will be extended until the release of HHVM 4.71, scheduled for next week.

HHVM 4.69 is released! This release marks the end of support for 4.62; HHVM 4.64–4.68 remain supported, as do the 4.32 and 4.56 LTS releases.

Breaking Changes

• Directly implementing the same interface twice with multiple generics is now banned, due to incorrect over-permissiveness; for example, in class Foo implements IBar<string>, IBar<int> {}, only IBar<string> would be properly enforced.
• The hhvm.check_return_type_hints runtime option has been removed.
• It is now a typechecker error to attempt to directly construct an IntlIterator.
• Building an authoritative repository (repo-auth-mode) will now fail if you have duplicate classes, type aliases, or records (potential future feature) with the same name. Previously, it was an error to have two classes with the same name or two type aliases, but not an error to have a type alias with the same name as a class, for example.
• fun() now returns a distinct type, not a string; this will not pass string typehints. For now, string variables are still invocable, but this will change, and is highly discouraged.

HHVM 4.68 is released! This release marks the end of support for 4.61; HHVM 4.62–4.67 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• Hack no longer reports duplicate errors when an invalid type constant is referenced from another type constant.

Breaking Changes

• The array type has been completely removed from HHVM. All arrays are now either varray or darray, which are treated as separate incompatible types by both the typechecker and the runtime.
  • In recent HHVM versions, it had already been impossible to create array values that are neither varray or darray from Hack code, but some built-in functions could still return them. These have all been migrated to return varray or darray now.
  • The type varray_or_darray with either one or two generic parameters can be used to migrate code that needs to accept/return both types of arrays. However, using Container or KeyedContainer is usually preferable for any code that is intended to work with multiple array-like types.
  • Migrating array type annotations to varray_or_darray is guaranteed to be safe in HHVM 4.68. In previous HHVM versions, it is safer to use <<__Soft>> varray_or_darray, as it is possible to have array values that are neither varray nor darray, depending on the exact INI options.
  • Migrating array type annotations to varray and darray (or even vec and dict) might be preferable, but it may cause runtime errors, possibly undetected by the typechecker (for values coming from untyped code including some built-ins). You can use <<__Soft>> to turn these errors into warnings.
  • Automated migrations for array type annotations are available in HHAST v4.64.4.
• The built-in functions each, next, prev were removed. Any other built-ins that use arrays’ “internal iterator” (current, key, reset, end) will also be removed soon.
  • Additional iterators and related classes were removed:
    • all methods of ArrayIterator other than current, key, next, rewind, valid
    • AppendIterator
    • CachingIterator
    • CallbackFilterIterator
    • LimitIterator
    • MultipleIterator
    • ParentIterator
    • RecursiveArrayIterator
    • RecursiveCachingIterator
    • RecursiveCallbackFilterIterator
    • RecursiveTreeIterator
    • SplFixedArray
    • SplObjectStorage
• Attempting to merge arrays using the + or += operators now throws an exception. It had already been a typechecker error.
  • In recent HHVM versions, you can use the INI options hhvm.hack_arr_compat_notices=true and hhvm.hack_arr_compat_check_array_plus=true to raise a notice.
• Fixed the position at which the typechecker reports an error for a missing type constant. This may require some HH_FIXMEs to be moved.
• Using meth_caller with a trait now raises a typechecker error. Runtime behavior hasn’t changed, HHVM currently allows constructing such meth_caller but throws an exception when the method call is invoked.
• By default, HHVM now raises a warning for any switch statements where none of the cases matched the provided value. In the future, this will be changed to throw an exception.
  • A default branch should be added to any switch statements that intentionally don’t cover all possible cases.
  • Use the INI option hhvm.throw_on_non_exhaustive_switch=0 to temporarily disable this warning, or hhvm.throw_on_non_exhaustive_switch=2 to enable the future behavior now (throw an exception).
• By default, HHVM no longer allows user-defined error handlers to silence the errors when function return type annotations are violated.
  • This is only relevant if the INI option hhvm.php7.engine_exceptions is set to false. If this option is true (default), return type violations throw a TypeError which can be caught, but it is never possible to continue execution in the same scope.
  • The INI option hhvm.check_return_type_hints can be used to temporarily reduce this to a recoverable error or a warning, but this option will be removed in the future.
• By default, HHVM now raises a warning if any type annotations on properties (static and instance variables) are violated. In the future, this will be changed to throw an exception.
  • The INI option hhvm.check_prop_type_hints can be used to temporarily disable the warning or to enable the future behavior now.
• Generic type parameters with upper bounds (TFoo as FooBaseClass), when used as function parameter or return types, will now raise a warning if the upper bound is violated. This had already been a typechecker error, but previously ignored at runtime.
  • Note that only the upper bound is enforced at runtime, so code shouldn’t rely on any assumptions stronger than that. In the above example, HHVM will enforce that TFoo is an instance of some subclass of FooBaseClass, but can’t enforce that it matches the exact type of TFoo in the given context, as generic types are erased at runtime.
  • Use the INI option hhvm.enforce_generics_ub=0 to temporarily disable this warning, or hhvm.enforce_generics_ub=2 to enable the future behavior now (throw an exception).
• The INI option hhvm.forbid_thrift_integer_values_out_of_range (used by the Thrift extension) has been removed.

Future Changes

• Arrays will soon no longer maintain an “internal iterator”, which should reduce their memory usage. Any built-ins that depend on the internal iterator are either already removed (each, next, prev) or will be removed soon (current, key, reset, end).
  • Most users of these iteration APIs can be rewritten with foreach loops, and would be much faster to boot. For cases that can’t be converted this way, you can use Vec\keys($array) to get an array of keys and vec($array) to get an array of values and use a for loop over indices for these two arrays.
• The INI options mentioned above are expected to have stricter defaults and/or be removed completely in the future:
  • hhvm.throw_on_non_exhaustive_switch
  • hhvm.check_return_type_hints
  • hhvm.check_prop_type_hints
  • hhvm.enforce_generics_ub

HHVM 4.67 is released! This release marks the end of support for 4.60; HHVM 4.61–4.66 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• Server stats are now cleared after warmup, to reduce noise from requests that should be unrepresentative.
• Runtime type errors now consistently say varray or darray as appropriate, instead of just array.

Breaking Changes

• An exception is now thrown when a file contains top-level code.
• HackC will no longer emit top-level code outside of the debugger.
• Backticks are no longer parsed as quotation separators; they were previously equivalent to double quotes.
• (array) casts are now disabled in the runtime.

HHVM 4.66 is released! This release marks the end of support for 4.59; HHVM 4.60–4.65 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• HH\is_any_array() now refines the type of its argument to KeyedContainer. This doesn’t change what programs are accepted by the typechecker, but results in clearer error messages for those that aren’t.

Breaking Changes

• Casting any array (vec, dict, keyset, varray, darray) to string now throws an exception at runtime. It had already been a typechecker error.
• Using a non-int/string array index is now a runtime error. It had already been a typechecker error.
  • In recent HHVM versions, this behavior can be enabled using the INI options hhvm.hack_arr_compat_notices=1 and hhvm.hack_arr_compat_check_array_key_cast=1.
• Fixed a bug that caused strtr(), when called with a darray that contains int-like keys, to silently ignore them (strtr('123', darray['2' => 'x']) now correctly returns '1x3'). The behavior is now consistent with dict, which wasn’t affected by this bug.
• The typechecker now reports an error if there are multiple <<__EntryPoint>> functions in a file. It had already been a runtime error.
• The typechecker now reports an error when comparing an enum value with a value of an incompatible primitive type. This may reveal new errors of the form “This expression is always false”.
• Fixed a bug where the typechecker would not report an error when a trait with generic parameters that depend on each other is used incorrectly (e.g. trait Foo<Ta, Tb as Ta> with use Foo<string, int>). This may reveal previously undetected errors.
• Fixed a bug that caused the typechecker to incorrectly conflate generic types on a class and its methods in some cases. This may reveal previously undetected errors (example).

Future Changes

• “plain arrays” (PHP arrays created by array(...)) are going away. In a previous release, we eliminated the Hack syntax for these arrays, but some builtins (e.g. array_intersect_key() and many other array builtins) could still produce them. We will change these builtins to return darray instead.
  • darrays behave nearly identically to plain arrays. The full list of behavior differences is as follows:
    • Plain arrays support relational comparison (<, <=, >, >=); darrays throw on comparison.
    • Plain arrays don’t compare equal to darrays with the same elements.
    • Plain arrays fail darray typehints, while darrays pass them.
  • The typehint behavior difference shouldn’t cause problems; it only affects behavior that currently causes TypehintViolationException which should be quite uncommon.
  • For the comparison cases, turn on: hhvm.hack_arr_compat_notices and hhvm.hack_arr_compat_check_compare and look for the following two notices:
    • “Comparing two plain arrays relationally”
    • “Comparing plain array and darray”
  • The first notice here will become an error; the second one may return true where it currently returns false (and so requires manual inspection). We don’t expect either case to be common.
• If a function has a parameter with an invalid default value, accessing it via ReflectionFunction or ReflectionMethod may currently throw. In the future, it will only raise a warning (making reflection safer to use).
  • Use the INI option hhvm.fix_default_arg_reflection=2 to enable the future behavior now.
• In the future, using class_meth with an abstract function will be a runtime error. Currently, this is only a runtime error if the method is actually called.
  • Use the INI options hhvm.emit_cls_meth_pointers=1 and hhvm.is_compatible_cls_meth_type=1 to enable this behavior now.
• Output of var_dump() will start differentiating between varrays and darrays.
  • Use the INI option hhvm.hack_arr_dv_arr_var_dump=1 to enable this behavior now.

HHVM 4.65 is released! This release marks the end of support for 4.58; HHVM 4.59–4.64 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• is and as checks for reified enums now only check the underlying type, not the values; this makes them consistent with parameter and return type enforcement.
• added _with_error() variants of preg functions, e.g. preg_grep_with_error(), preg_match_with_error(), preg_replace_with_error(), to avoid the need for preg_last_error() calls and the global state that entails.
• added HH\is_vec_or_varray() and HH\is_dict_or_darray() functions.
• clearer error messages when incompatible kinds extend each other - for example, a class can not extend an interface, but it can implement one.

Breaking Changes

• array() literals are no longer supported by the parser; [] literals were already banned. Replace with darray[] or varray[]. On older versions of HHVM, hhast-migrate --php-arrays can be used to automate this.
• the globals array has been removed - for example, HH\global_get('GLOBALS') now returns null. Fetch specific known keys instead.
  • $GLOBALS['foo'] (i.e. with a key) is still supported, however migrating to HH\global_get('foo') is encouraged.
• it is now a typechecker error to mark an abstract method as __Memoize; this was previously a runtime error.
• yield from has been removed; the release notes for 4.64 contain suggestions for migrating.

Future Changes

• (array) casts will be a parse error; they are currently a typechecker error. A runtime error can be enabled now with the new hhvm.hack.lang.disable_array_cast INI setting.

A security update has been released for all supported HHVM versions. Please update to one of the following versions to make sure you’re secure:

• 4.32.3
• 4.56.1
• 4.57.1
• 4.58.2
• 4.59.1
• 4.60.1
• 4.61.1
• 4.62.1
• 4.64.0 (new version released today)

This security update addresses the following vulnerabilities:

• value of hhvm.admin_server.password could be revealed by functions like ini_get(), ini_get_all(), phpinfo()
• CVE-2020-1898: possible crash (stack overflow) because of a missing nesting limit in fb_unserialize(), fb_compact_unserialize()
• CVE-2020-1899: arbitrary memory access in unserialize() if type code ‘S’ is used maliciously
• CVE-2020-1900: possible use-after-free in unserialize() when unserializing an object with dynamic properties

HHVM 4.64 is released! This release marks the end of support for 4.57; HHVM 4.58–4.62 remain supported (4.63 was skipped), as do the 4.32 and 4.56 LTS releases.

Breaking Changes

• The INI flag hhvm.hack_arr_compat_specialization was removed and its behavior is now enabled by default. This change disables the implicit interoperability between varrays and darrays. Instead, array (soon to be removed), varray and darray are now treated as types in their own right. Specifically:
  • Using a varray where a darray is expected (at parameter and return value typehints) throws, and vice versa. The same goes for property typehints, if they are checked at runtime.
  • varrays now maintain a “vec-like” layout, with integer keys from 0 to (size - 1). Attempting to set a string key in a varray throws, as does 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(...) returns false and darray as tuple(...) throws. The same goes for varray is shape(...) and varray as shape(...).
  • Comparing a varray and a darray using == or === always returns false.
  • Comparing a darray with a varray, or two darrays using >, <, <=, >=, <>, <=> results in an exception. Two varrays can still be compared.
  • If property type enforcement is turned on, property type invariance rules for class hierarchies will apply to varray, darray and array. For example, a child class will not be able to redeclare a property with type varray<Tv> if the parent class’ property is typed darray<Tk, Tv>.
  • Additional related INI flags were removed, since they no longer have any effect:
    • hhvm.hack_arr_compat_type_hint_notices
    • hhvm.hack_arr_compat_check_varray_promote
    • hhvm.hack_arr_compat_check_implicit_varray_append
    • hhvm.hack_arr_compat_dv_cmp_notices
• Attempting to override a non-abstract constant defined in an interface when implementing or extending that interface is now a typechecker error. It had already been a runtime error.
• The function HH\global_keys() was removed. Other methods of enumerating all global variables, such as HH\global_get('GLOBALS') or $GLOBALS['GLOBALS'], are also expected to stop working soon.

Future Changes

• 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
• Any remaining methods of enumerating all global variables, such as HH\global_get('GLOBALS') or $GLOBALS['GLOBALS'], are expected to stop working in a future release.
• We expect to remove the yield from syntax in a future release. In most cases, it can be replaced by other syntax.

Replacing yield from

Here’s a list of replacements to use based on the complexity of the use case:

If only the values, or only (key, value) pairs, are used, replace yield from with foreach...yield:

1
2
3
4
5
6
7
8
9
10
11
12
13
function only_values_old($gen) {
  yield from $gen;
}
function only_values_new($gen) {
  foreach ($gen as $v) { yield $v; }
}

function keys_values_old($gen) {
  yield from $gen;
}
function keys_values_new($gen) {
  foreach ($gen as $k => $v) { yield $k => $v; }
}

Use getReturn to evaluate the result of the yield from expression:

1
2
3
4
5
6
7
8
9
function return_old($gen) {
  $x = yield from $gen;
  var_dump($x);
}
function return_new($gen) {
  foreach ($gen as $v) { yield $v; }
  $x = $gen->getReturn();
  var_dump($x);
}

Use send to pass values back into the inner generator (if callers of the yield from outer generator do so). This use case is quite rare.

1
2
3
4
5
6
7
8
function send_old($gen) {
  yield from $gen;
}
function send_new($gen) {
  for ($gen->next(); $gen->valid(); $gen->send($s)) {
    $s = yield $gen->key() => $gen->current();
  }
}

There’s one behavior of yield from syntax that can’t be captured easily by rewrites like the above: if the same generator is aliased by a yield from and elsewhere, next() on that generator will advance the yield from. Such code will need a rewrite to make state explicit.

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 Changes

We 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 interoperability 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 false.
  • Attempting to compare varrays to darrays relationally with <, <=, >, or >= will result in an exception.

HHVM 4.62 is released! HHVM 4.57–4.61 remain supported, as do the 4.32 and 4.56 LTS releases.

Highlights

• added json_encode_with_error() and json_decode_with_error(), which take a new inout ?(int, string) $error parameter as their second argument, instead of mutating global state (which would be retrievable via json_last_error()).
• fixed several resource lifetime bugs in the gd, icu, and zip extensions, which could lead to resources being prematurely freed when another resource held a reference to them.
• improved source locations for inout errors.

Breaking Changes

• A parser error is now raised if Vector, ImmVector, Set, or ImmSet are initialized with keys, or if Map or ImmMap are initialized without keys. Previously, this would lead to a bytecode emitting error.
• FIXME codes now need whitelisting in the project root .hhconfig

FIXME whitelisting

FIXME codes must now be whitelisted in the top-level project’s .hhconfig - adding a FIXME for a code that is not in the whitelist is in itself an error. The relevant configuration options are:

• allowed_fixme_codes_partial=1234,5678: FIXME codes that are permitted in .hackpartial files.
• allowed_fixme_codes_strict=1234,5678: FIXME codes that are permitted in all other files, including .hack files and .php files starting with <?hh - including <?hh // partial. We still recommend moving to .hack and .hackpartial files, and expect support for // partial to be removed in a future release.
• allowed_decl_fixme_codes=1234,5678: FIXME codes that are permitted in declaration contexts, such as function type signatures. Any codes here must also be listed in the _strict or _partial options to be permitted in those files; this is to allow banning a code from strict files, while still permitting it in decl contexts in partial files.

For example, the HSL is configured with:

1
2
allowed_decl_fixme_codes=2053,4045
allowed_fixme_codes_strict=2011,2049,2050,2053,4027,4045,4106,4108,4110,4128,4135,4188,4200,4240,4248,4297,4323

A script is available to generate these configuration options; this script requires jq version 1.6 or newer.

This change is intended to allow projects to control what kinds of unsafe operations they are comfortable permitting, and to avoid accidentally regressions and introducing new forms.

Empty strict/partial whitelists are likely not a practical goal for the majority of projects at this time, however, there is significant benefit in entirely eliminating fixmes in declaration contexts, so we recommend that all projects attempt to have an empty allowed_decl_fixme_codes whitelist.

HHVM 4.61 is released! This release marks the end of support for 4.55; HHVM 4.56–4.60 remain supported, as does the 4.32 LTS release.

Highlights

• The typechecker no longer reports multiple redundant errors when a class (interface) is extended (implemented) with incompatible generic type parameters (example).
• Fixed a bug where using array_unshift on a keyset could cause the keyset to contain multiple identical values.

Future Changes

• Support for HH_IGNORE_ERROR may be removed in the future, making HH_FIXME the only way to silence typechecker errors.
  • You can add disable_hh_ignore_error=true to your .hhconfig to get this behavior now.

HHVM 4.60 is released! This release marks the end of support for 4.54; HHVM 4.55–4.59 remain supported, as does the 4.32 LTS release.

Highlights

• Added hh_parse --pretty-print-json
• Improved error readability for recursive types.
• Shapes::idx() now permits null as the first argument, for consistency with idx().

Breaking Changes

• Fix typing bug that allowed calling invalid static methods on reified generics, e.g. function test<reifiy T as arraykey>() : void { T::foo(); }
• Removed Exception::setPreviousChain(); using this was already a type error as it was not in the HHI files.

HHVM 4.59 is released! This release marks the end of support for 4.53; HHVM 4.54–4.58 remain supported, as does the 4.32 LTS release.

Highlights

• Improved output of hh_client to more accurately describe the status of the server in various cases.

Breaking Changes

• The typechecker now raises an error if any attribute arguments (<<Attr('arg1', 'arg2')>>) are not literal values. These had already been runtime errors.
  • Array, shape and tuple literals are allowed.
• The .hhconfig option stronger_shape_idx_return has been removed. This was an experimental option that was never enabled by default, so this change should not affect most users.
• If a where constraint on a constructor isn’t satisfied at the point of using new, the typechecker would previously raise an error pointing to the constructor definition. Instead, it now points to the use (the new construct).
  • This provides more helpful output and fixes an issue where typechecking a file could raise an error in a different file, but it may require some HH_FIXMEs to be moved.

HHVM 4.58 is released! This release marks the end of support for 4.52; HHVM 4.53–4.57 remain supported, as does the 4.32 LTS release.

Highlights

• Errors for cyclic definitions (e.g. when using type aliases) are no longer duplicated, or raised in files that merely use a problematic type.
• If an error is raised for type constant in a superclass, duplicate errors are no longer raised for subclasses.
• When trait methods are incorrectly overridden, the typechecker now reports errors at the override, instead of at the original trait definition.
• Added .hackpartial files, to replace <?hh // partial; like .hack files, these must not contain a header line. See ‘future changes’ for upcoming breaking changes related to partial files.
• Fixed issues passing FDs to child processes via proc_open when using LightProcess, especially when STDIN was not specified, or other low-numbers FDs were specified.

Breaking Changes

• Support for soft type hints using @ (e.g. @int $foo) has been disabled; use <<__Soft>> int $foo instead.
• Static closures (e.g. $f = static function() { return 1;}) has been disabled as they were never safely typechecked.
• goto is now a parse error; it has never been supported in Hack code.
• $foo[] += $bar is now a typechecker error.
• it is now an error for <<__EntryPoint>> functions to take arguments.
• typechecker errors are now raised if built-in attributes are used in invalid places, for example, __Override on a standalone function (i.e. not a method).
• Error code 4005 (bad array access) has been split into:
  • 4005: array access on unsupported type (read)
  • 4370: array access on unsupported type (write)
• Error code 4298 (bad array key) has been split into:
  • 4298: array access with invalid key type (read)
  • 4371: array access with invalid key type (write)
• Error code 4062 (member on non-object) has been split into:
  • 4062: member read on non-object
  • 4373: member write on non-object
• Error code 4064 (member on null) has been split into:
  • 4064: member read on null
  • 4372: member write on null

Future Changes

• Support for <?hh // partial will be removed; use .hackpartial files instead.
• We are expecting to entirely remove partial mode in early 2021 - this will include ending support for .hackpartial files. We strongly recommend migrating any remaining partial code in 2020.
• non-literal attribute arguments will be a type-error; previously the typechecker would permit them, but HHVM would fatal at runtime.

HHVM 4.57 is released! This release marks the end of support for 4.51; HHVM 4.52–4.56 remain supported, as does the 4.32 LTS release.

Highlights

• Shapes::idx() now accepts a nullable first argument (consistently with idx()).

Breaking Changes

• We no longer build packages for Ubuntu 16.04 (Xenial), Debian 8 (Jessie), and Debian 9 (Stretch). Building from source is also no longer supported on systems with GCC 6 or older, or with OpenSSL older than 1.1.0.
• Docker images are now based on Ubuntu 20.04 instead of 18.04.
• Attempting to declare the “magic method” __call is now a parser error. It had already been a typechecker error, but now it is also a fatal error at runtime.
• The typechecker no longer declares FormatString in the root namespace (\FormatString). Use \HH\Lib\Str\SprintfFormat (compatible with \HH\Lib\Str\format()) or \HH\FormatString (compatible with sprintf()) instead.
• Fixed a bug where accessing an instance variable of a dynamic value could cause the typechecker to report an error with primary position in a different file. This doesn’t introduce any new errors but may require some HH_FIXMEs to be moved.

Future Changes

• In a future release, the internal representation of function/method references (i.e., the values returned by fun(), class_meth(), or inst_meth()) may change.
  • Currently, the internal representation is a string (for functions), or an array (for methods). In the future, this will likely change to a native function/method reference type, incompatible with string/array. Any code that relies on the current internal representation (e.g. by passing a function reference where a string is expected) will need to be fixed.
  • It is already a typechecker error to use function/method references in place of string/array values, so the change only affects runtime behavior of code that uses HH_FIXME to squelch the typechecker error.
  • The INI option hhvm.enable_func_string_interop=0 can be used to test the new behavior now.

HHVM 4.56 is released! This release has long term support, so:

• this release will be supported for approximately 48 weeks
• the next LTS will be released in approximately 24 weeks
• HHVM 4.32 (LTS) and HHVM 4.51–4.55 remain supported.
• support has ended for HHVM 4.8 (LTS)

Additionally, 4.56 is the last release with support for several older Linux distributions and MacOS versions. In particular, we expect this to be the last release with support for Ubuntu 16.04 (Xenial), Debian 8 (Jessie), and Debian 9 (Stretch). See ‘Future Changes’ below for details.

Highlights

• apc_fetch() expiration is now deferred until the end of the first request that sees an expired result; this request will return false, but any concurrent requests will see the old value until the first request has finished. This change aims to reduce ‘thundering herd’ problems when many requests simultaneously attempt to refresh a hot key.

Breaking Changes

• \HH\INCORRECT_TYPE<T> has been removed from the HHI definitions.
• Support for __get, __set, __isset, and __unset has been removed from HHVM and the parser. Builtin classes that used these with fixed property names have a new native implementation.
• The Redis extension has been removed. This extension contained no native code, so can be extracted from past versions of HHVM and updated as a standalone library if required, though we do not support this usage.

Future Changes

As announced in November, we are changing our distribution support lifecycle, starting with nightly builds and the next release:

• MacOS: we aim to support the latest stable release - currently Catalina. When a new version of MacOS is released, we plan to support both for 6 months.
• Debian: we aim to support Debian stable. When a new version is promoted to stable, we plan to support both for 6 months.
• Ubuntu LTS: we aim to support the current LTS release (20.04); when a new Ubuntu LTS is released, we plan to support both for the next 6 months.
• Ubuntu ‘interim’ releases: we plan to support these for 9 months, matching the length of time they are supported by Canonical.

As long as dependencies are available from official upstream repositories, we plan to package x.y.z releases for any Linux distributions where we packaged x.y.0; we also aim to do this for MacOS as long as the versions are available from our build infrastructure provider.

Concretely, this means that we no longer commit to supporting:

• Debian 8 (Jessie)
• Debian 9 (Stretch)
• Ubuntu 16.04 (Xenial)
• MacOS 10.14 (Mojave)

We will generally keep building packages for distributions we no longer support as long as they keep working and they do not hold back development. That said, starting with 4.57, we are immediately ending support for distributions that include GCC6 or below:

• Debian 8 (Jessie)
• Debian 9 (Stretch).
• Ubuntu 16.04 (Xenial)

Other unsupported distributions may be removed from future releases without further notice.

A security update has been released for all supported HHVM versions. Please update to one of the following versions to make sure you’re secure:

• 4.8.8
• 4.32.2
• 4.49.1
• 4.50.1
• 4.51.1
• 4.52.2
• 4.53.1
• 4.54.1
• 4.55.1

This security update addresses the following vulnerabilities:

• If the GlobalDocument request routing mode is used, it is possible to infer the existence of arbitrary source code directories. This issue doesn’t affect HHVM 4.8, since it doesn’t support GlobalDocument.

The following were originally reported as PHP vulnerabilities, but HHVM is also affected:

• CVE-2019-9638
• CVE-2019-9639
• CVE-2019-9640
• CVE-2019-11034
• CVE-2019-11038
• CVE-2019-11041
• possible buffer overrun in exif_read_data()
• possible buffer overrun in socket_sendto()
• sodium_crypto_generichash_init() leaks data from uninitialized memory

HHVM 4.55 is released! This release marks the end of support for 4.49; HHVM 4.50–4.54 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• We now also build binary packages for Ubuntu 20.04.
• Improved typechecker error messages for various cases where a subclass incorrectly overrides a method or property from a parent class.
• Fixed a bug that would cause the typechecker to report some instance variables or static variables as uninitialized, even if they are nullable.
  • Instance/class variables must be initialized either as part of the variable’s declaration or inside the class’ constructor, but only if they are non-nullable. The typechecker would previously not correctly detect all nullable variables when generics or type aliases were involved.

Breaking Changes

• Comparing Hack arrays (vec, dict, keyset) to true, false, and null with the “fuzzy” equality operators (==, !=) now considers non-empty Hack arrays == true, and empty Hack arrays == false and == null.
  • In HHVM 4.49 to 4.54, the INI option hhvm.hack_arr_empty_based_bool_eq_cmp=true can be used to enable this behavior.
  • The new behavior is consistent with legacy arrays, making it easier to migrate to Hack arrays.
• The typechecker no longer completely ignores arguments of calls on values of type nothing. As before, any number/types of arguments are allowed (due to nothing being Hack’s bottom type), but previously ignored nonsensical arguments like 1 + 'foo' are now rejected.
• The %s placeholder in printf() now expects an ?arraykey argument instead of mixed.
  • In the future, we expect implicit string casts on arrays and objects to raise exceptions. This change should make it easier to find such dangerous casts earlier.
  • Str\format() is unchanged, it has always expected a string argument.
• Boolean .hhconfig options now treat the value 2 (as well as any other value except 1/true/yes/on) as false. Previously, the behavior was not consistent across all boolean options, sometimes all positive numbers were treated as true.
  • This is most likely to affect options that previously had 2 as a valid value, but later became boolean options (a somewhat common pattern).

HHVM 4.54 is released! This release marks the end of support for 4.48; HHVM 4.49–4.53 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• inout parameters on async functions now only raise a parse error, instead of a parse error and a NastCheck error.
• improved accuracy of line numbers for errors or backtraces within concurrent blocks
• The ignored_fixme_codes (errors that can not be suppresed) hack option is no longer respected for HHI files; this allows projects to use a stricter list than is compatible with builtins.
• If using CLI server mode, a warning is now logged if the CLI client does not recognize a command sent to the CLI server. We strongly recommend using the hhvm.check_cli_client_commands=2 INI setting to raise an error instead: these warnings indicate a bug in HHVM, and can not be safely recovered from. If you see this warning, please file a bug report. It can also be set to 0 to disable the warnings. Any value other than 2 leads to undefined behavior in this error case.
• Increased the efficiency of idx() and array access on empty containers.

Breaking Changes

• Containers are now more consistently checked for valid arraykeys; this behavior can be enabled on old releases with the disallow_invalid_arraykey=true .hhconfig setting.

Future Changes

• The hhvm.check_cli_client_commands INI setting will default to 2 (error) in a future release.

HHVM 4.53 is released! This release marks the end of support for 4.47; HHVM 4.48–4.52 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• We now build binary packages for Ubuntu 19.10. Packages for Ubuntu 20.04 should become available after its final release.
• The type-checker now provides more helpful error messages when cyclic shape type aliases are detected, pointing out both the invalid type alias and the cause of the cycle.

Breaking Changes

• ?> can no longer be used to terminate // comments (?> for all other purposes was removed in HHVM 4.52)

HHVM 4.52 is released! This release marks the end of support for 4.46; HHVM 4.47–4.51 remain supported, as do the 4.8 and 4.32 LTS releases.

HHVM 4.52.1 fixes a regression introduced in 4.52.0, which made the typechecker report Hack parse errors in PHP code, instead of ignoring actual PHP source files.

Highlights

• fixed crash in ext_soap if a SoapServer’s handler class does not exist.
• ?> and <?= are no longer recognized by the parser; this has replaced dedicated errors with parse errors.

Breaking Changes

• it is now a type error to use the same trait twice in the same class; using the same trait in related classes (e.g. subclasses and parents) is still permitted.

Future Changes

• Runtime support for casting objects to strings via __toString will be removed shortly; this includes (string) $obj, print($obj), sprintf('%s', $obj) among others. The hhvm.notice_on_implicit_invoke_to_string INI setting can be used to find calls that will break.

HHVM 4.51 is released! This release marks the end of support for 4.45; HHVM 4.46–4.50 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• A new method getEnumUnderlyingType() was added to ReflectionClass. It returns the underlying type of the enum’s values (usually HH\int or HH\string, but can also be the name of another enum, type alias, or HH\arraykey).
  • If the ReflectionClass instance doesn’t represent an enum, the method throws.
• Improved optimization of async tail calls (return await ...) can significantly improve performance of code that uses a lot of such calls.

Breaking Changes

• Using the array-appending operator [] on a Map object ($map[] = Pair {$key, $value};) is now a type-checker error.
  • Use $map[$key] = $value; instead.
  • The runtime still allows both variants, so HH_FIXME can be used temporarily, to help migrating code. Runtime support will likely be removed in a future release.
• The type-checker no longer supports the “magic method” __call, so calling any method that is not explicitly declared is now a type-checker error.
  • Runtime behavior is unchanged, so HH_FIXME can be used temporarily, to help migrating code. Runtime support will likely be removed in a future release.
  • In the long term, we recommend migrating any affected code to only call explicitly declared methods.

Future Changes

• We expect the removed type-checker features listed above to also be removed from the runtime in a future release.

HHVM 4.50 is released! This release marks the end of support for 4.44; HHVM 4.45–4.49 remain supported, as do the 4.8 and 4.32 LTS releases.

Additionally, we are no longer building binary packages for MacOS High Sierra for any version of HHVM, as High Sierra is no longer offered by our build infrastructure provider.

Highlights

• added the hhvm.hack_arr_is_shape_tuple_notices INI setting, which raises a notice on $dict is shape() and $vec is tuple(); these are currently always false, but may be true in the future, so are unsafe to depend on.
• HH\BuiltinEnum<T> is now covariant.
• Improve hackfmt’s range formatting when suppressions outside the requested range affect code within the requested range.

Breaking Changes

• magic methods (__get, __set, __isset, __unset) have been removed from the typechecker definitions of builtins, such as the XMLReader, Imagick, DateTime, and SimpleXML extensions.
• it is now a type error to use argument unpacking when invoking a default constructor. It was already an error to make a variadic call to functions that take exactly zero arguments, and as default constructors always have exactly zero arguments, this makes the behavior consistent. This was previously a runtime error.

Future Changes

• array() literals will be removed; the hhvm.hack.lang.disable_array=true INI setting can be used to enable a runtime fatal when they are used, in addition to the preexisting disallow_array_literal=true .hhconfig option.
• The magic methods on builtins that were removed from the typechecker in this release will be removed from the runtime in a future release.

HHVM 4.49 is released! This release marks the end of support for 4.43; HHVM 4.44–4.48 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• New .hhconfig option disable_modes (previously disable_partial) will cause the typechecker to treat all files as strict (comments after <?hh no longer have special meaning).
  • The default value will be false for the foreseeable future.
• New hackfmt flag --format-generated-code can be used to format generated and partially generated files.
• Fixed a bug that could cause part of hackfmt output to be missing when formatting partially generated files, and other minor fixes and improvements for hackfmt.
• Fixed a bug that could prevent the “go to type” IDE feature from working inside async functions.
• Improved various typechecker error messages, e.g. when accessing an optional shape field it now recommends using Shapes::idx instead of ??.

Breaking Changes

• Comparing (<, >, <=, >=, <=>) a legacy PHP array with a non-array now throws InvalidOperationException (previously only raised a Notice). It had already been a typechecker error.
• It is now a runtime error if class_meth is used with arguments that are not a ::class and a string literal (a string literal as the 1st argument will also not cause a runtime error, but ::class literal is recommended). It had already been a typechecker error.
  • If a dynamic pointer is required, annotate the method with <<__DynamicallyCallable>> and use HH\dynamic_class_meth().

Future Changes

• We are working towards deprecating (and eventually removing from the language) “magic methods” such as __call or __get. Currently, you can use the INI option hhvm.no_use_magic_methods=true to trigger warnings whenever a magic method is invoked, e.g. when an undefined method is called on a class that has the __call magic method.
• Comparing Hack arrays to true, false, and null with the “fuzzy” equality operators (==, !=) will be changed so that non-empty Hack arrays are == true and empty Hack arrays are == false and == null.
  • The INI option hhvm.hack_arr_empty_based_bool_eq_cmp=true can be used to enable this behavior now.
  • The new behavior is consistent with legacy arrays, making it easier to migrate to Hack arrays.

HHVM 4.48 is released! This release marks the end of support for 4.42; HHVM 4.43–4.47 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• If a non-abstract class contains an abstract method, report the error at the location of the class name (where the abstract modifier should be), instead of at the function declaration.
• Some error code suppressions apply to line ranges, instead of nodes. hackfmt will now ignore any code in such a range, as formatting it could un-suppress errors.
• If a file generated by hack-codegen is partially generated, hackfmt will only format the manual sections.
• hackfmt will not modify files containing @generated.
• Updated and clarified error message for private methods - now “must be public or protected”, previously (incorrectly) “Access type […] must be omitted”.
• hh_client lsp --config now accepts .hhconfig settings, in addition to hh.conf (system-wide) settings.
• Error for uninitialized members now suggest making the property “nullable” instead of “optional”, to avoid confusion with shape terminology.
• Suggest using $x is SomeEnum if an exhaustive switch statement contains a default: block.
• The CLI client/server protocol version has changed; if you have configured CLI client/server and deploy them separately, this may lead to fallback to standalone CLI mode.

Breaking Changes

• It is again an error to have a default case in exhaustive switch ($enum) blocks; while the enum is not enforced at runtime, we feel this behavior is better as it raises an error when the enum is expanded but switch statements are not. Note that a switch statement that does not match (no matching case, no default) are still expected to throw an exception in a future release, or now with the hhvm.throw_on_non_exhaustive_switch=2 setting.
• HHVM_VERSION_ID is of the form XXYYYZZ instead of XXYYZZ; if you are extracting parts, please use the HHVM_VERSION_MAJOR, HHVM_VERSION_MINOR, and HHVM_VERSION_PATCH constants instead.

Future Changes

• added disable_partial (will be renamed disable_modes shortly) - a boolean flag that disables partial mode (and all other modes!) from Hack completely. Comments after the <?hh are just comments, and non-hhi files are inherently strict. The default value will be false for the foreseeable future.

HHVM 4.47 is released! This release marks the end of support for 4.41; HHVM 4.42–4.46 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• We’re looking to help people migrate towards strictness! Part of that is a series of .hhconfig flags:
  • ignored_fixme_codes: a comma delimited list of error codes (4110, 2071, etc.) that allow you to gradually forbid HH_FIXMEs in your codebase. Hack will ignore any HH_FIXME or HH_IGNORE_ERROR with the specified codes. An empty list is the default, meaning only the hardcoded unfixmeable codes (see default_ignored_fixme_codes in errors.ml) are forbidden.
  • disallowed_decl_fixmes: a comma delimited list of error codes (4110, 2071, etc.) that allow you to gradually forbid HH_FIXMEs in your codebase. Hack will ignore any HH_FIXME or HH_IGNORE_ERROR outside of the body of a function with the specified codes. Declaration-level FIXMEs tend to obscure more errors than intended, so tend to be more important to fix up.
  • error_codes_treated_strictly: a comma delimited list of error codes (4110, 2071, etc.) that allow you to gradually forbid HH_FIXMEs in your codebase. Partial mode files accept a number of errors that are not allowed in strict mode. If an error is in this list, we will report it as an error—even in a partial mode file. Not every error and position can be reported clearly though. Certain errors (like missing types) can cascade into other code, yielding other error codes or being hidden by partial mode. Still, this list can provide a means to incrementally fix things in partial mode files without strictifying the whole file. The default is an empty list, which uses the normal partial/strict modes.

Breaking Changes

• Trying to declare a function, constant, or enum type with the same name as a preceding use function, use const, or use type declaration is now a parser error.
  • It had already been a runtime error.
  • This makes the behavior consistent with classes, where it was already a parser error.
• namespace is now a reserved keyword, trying to use it as an identifier will result in a parser error.
  • It had already been a runtime error.
• HHVM_VERSION_ID is now XXYYYZZ instead of XXYYZZ.
  • This preserves compatibility for comparisons using </>, but breaks any code trying to parse HHVM_VERSION_ID into individual parts.
  • Use the new constants HHVM_VERSION_MAJOR, HHVM_VERSION_MINOR, HHVM_VERSION_PATCH (added in HHVM 4.42) instead of parsing the value.

Future Changes

• Support for XHP children declarations will be removed.
  • The XHPChildValidation trait from xhp-lib v3.1 should be used instead, see HHVM 4.46 release notes for more information and migration instructions.
  • New .hhconfig option disable_xhp_children_declarations=true can be used to get the future behavior now.

HHVM 4.46 is released! This release marks the end of support for 4.40; HHVM 4.41–4.45 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• clearer error message for unsuitably different expression types in case foo_expr: vs switch(bar_expr)
• removed typechecker error for ‘exhaustive’ enum switch statements with a default case; as enums are not enforced at runtime, these defaults are not strictly unreachable.
• added HH\autoload_get_paths(), returning a list of all files known to the autoloader.

Future Changes

• Support for XHP children declarations will be removed; special syntax is no longer required to support this feature, and allows more easily making it compatible with the main XHP type system.
  • xhp-lib v3.1 provides the new implementation, via two traits:
    • XHPChildDeclarationConsistencyValidation requires that the new and old forms of child declaration are equivalent
    • XHPChildValidation requires that only a new declaration is present
  • hhast-migrate v4.33.7 adds --add-xhp-children-declaration-method and --remove-xhp-child-declarations
• After support for XHP children declarations is completely removed, we expect to remove support for XHP category declarations: they are only used with children declarations, and by moving children declarations to standard Hack code, they can be replaced with normal interfaces.

A security update has been released for all supported HHVM versions. Please update to one of the following versions to make sure you’re secure:

• 4.8.7
• 4.32.1
• 4.38.1
• 4.39.1
• 4.40.1
• 4.41.1
• 4.42.1
• 4.43.1
• 4.44.1
• 4.45.1

This security update addresses vulnerabilies in JSON decoding:

• CVE-2020-1888: Insufficient boundary checks when decoding JSON in handleBackslash reads out of bounds memory, potentially leading to DOS.
• CVE-2020-1892: Insufficient boundary checks when decoding JSON in JSON_parser allows read access to out of bounds memory, potentially leading to information leak and DOS.
• CVE-2020-1893: Insufficient boundary checks when decoding JSON in TryParse reads out of bounds memory, potentially leading to DOS.

The new packages also include updates to some of the bundled dependencies:

• backported patch for CVE-2017-14107 in the bundled libzip library
• updated the bundled libsqlite3 library from 3.23.1 to 3.30.1, as the older version might be affected by multiple published vulnerabilities

Note that the bundled dependencies are only used on systems that don’t already provide those libraries.

HHVM 4.45 is released! This release marks the end of support for 4.38 and 4.39 (some versions were supported for longer than usual because 4.37 was skipped); HHVM 4.40–4.44 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• Fixed the type refinement done by is_array($value) to be less restrictive. The type-checker now understands the refined type to be the intersection of $value’s original type and varray_or_darray, instead of always rewriting the type to varray_or_darray.
  • For example, after passing a darray value to is_array, the type-checker no longer rewrites $value’s type to varray_or_darray but keeps treating it as a darray.
• New built-in functions HH\autoload_type_to_path(), HH\autoload_function_to_path() and HH\autoload_constant_to_path() can be used to look up entries in the autoload map (e.g. for debugging).
• hh_client --type-at-pos now returns additional information about how the type was determined.
• Various small clarifications in type-checker error messages (e.g. “missing property” instead of “missing member”).

Breaking Changes

• Empty switch statements are no longer allowed. They now produce a type-checker error as well as a fatal error at runtime, and in the future will be treated as a parsing error.
• The type-checker now raises an error for any lambda functions whose types cannot be inferred. This can reveal previously hidden type errors.
  • In previous HHVM versions, the new_inference_lambda=true option in .hhconfig enables this behavior.
• array_key_exists() now throws an InvalidArgumentException if the provided key is null.
  • In HHVM 4.44, the hhvm.hack_arr_compat_check_null_hack_array_key=true and hhvm.hack_arr_compat_notices=true INI options can be used to raise a notice.
• The ArrayAccess interface no longer provides its “magic” behavior. The interface still exists but its methods now need to be called directly (e.g. $stack->push(42) instead of $stack[] = 42;).
• When attempting to override a final method, the type-checker now raises an error in the child class instead of the parent class. This doesn’t introduce any new errors but may require some HH_FIXMEs to be moved.
  • The same change was made for class properties declared with <<__Const>> or <<__LateInit>>.
• Using a type constant via this as a reified generic type parameter in a type annotation (e.g. ClassWithReifiedGeneric<this::T> $arg) is now a type-checker error.
  • It is still allowed in function calls (foo<this::T>()) including constructor calls (new ClassWithReifiedGeneric<this::T>()).
• We no longer build packages for Ubuntu 18.10 (its official support ended in July 2019).

Future Changes

• array() literals will be removed; use vec/dict/keyset instead if possible, otherwise varray or darray.
  • Automated migration is available in HHAST 4.33.6: hhast-migrate --php-arrays
• The runtime will be changed to throw an exception for any switch statements where none of the cases matched the provided value.
  • A default branch should be added to any switch statements that intentionally don’t cover all possible cases.
  • Use the hhvm.throw_on_non_exhaustive_switch=2 INI option to enable this behavior now (or set the value to 1 to raise a warning instead of throwing an exception).
• Upper bounds on generic type parameters will be enforced at runtime. For example, passing true to a function declared as function takes_arraykey<T as arraykey>(T $arg) will be a runtime error in the future.
  • Any such violations already raise type-checker errors, but this could reveal new errors in code without full type coverage.
  • It is enforced regardless of where the generic parameter appears (function parameter and return types, class properties, etc).
  • Use the INI options hhvm.emit_generics_ub=true with hhvm.enforce_generics_ub=2 to enable this behavior now (or set the latter value to 1 to raise a warning instead of a fatal error).
• The behavior of is_array() will likely be changed to also return true for Hack arrays (vec, dict and keyset).
  • Currently it only returns true for legacy arrays (array, varray and darray). This change should make it easier to migrate from legacy arrays to Hack arrays.
  • New built-in function HH\is_php_array() was added in this release, which only returns true for legacy arrays (the current behavior of is_array()). You can replace any calls to is_array() with this function to guarantee no behavior changes in the future.
  • You can use HH\is_any_array() to preemptively migrate any is_array() calls to the future behavior.
• Comparing Hack arrays (vec, dict and keyset) with boolean values using the “fuzzy” comparison operators == and != will be changed to consider empty arrays equal to false and non-empty arrays to true.
  • This is consistent with how fuzzy comparisons work for other types, including legacy arrays (array, varray, darray). It should make it easier to migrate from legacy arrays to Hack arrays.
  • Strict equality operators === and !== are not affected, they will always evaluate to false when comparing values of different types. It is highly recommended to use these strict operators for comparisons and use C\is_empty() for checking the emptiness of arrays instead.
  • Use the hhvm.hack_arr_compat_hack_arr_cmp_notices=1 INI option to raise a notice whenever Hack arrays are compared with boolean values, and therefore the result may be affected by this future change.

HHVM 4.44 is released! HHVM 4.38–4.43 remain supported, as do the 4.8 and 4.32 LTS releases.

Breaking Changes

• the __Deprecated attribute is no longer permitted on any types, such as classes, enums, or type aliases; it had no effect in these positions.
• (int) NAN is now consistently the minimum 64-bit signed integer, instead of
  1. In previous releases, this behavior could differ at runtime compared to when constant-folding.
• square bracket literals for PHP arrays (e.g. ['foo', 'bar']) are now a parse error. array() is still supported, but will be removed in the near future. Ideally, use vec/dict/keyset instead, but varray and darray remain supported.

Future Changes

• comparison operations (e.g. <, <=, <=> etc) will be changed to throw when a PHP array is compared with a non-array. This operation currently raises a typechecker error, and raises a notice if hhvm.hack_arr_compat_notices=true and hhvm.hack_arr_compat_check_compare_non_any_array=true INI options are set. The behavior of !==, and === will not change.
• array_key_exists() will change to throw an exception if the specified key is null. A notice is raised if the hhvm.hack_arr_compat_check_null_hack_array_key=true and hhvm.hack_arr_compat_notices=true INI options are set.
• lambda type inference is being changed in the next release; the new behavior can be enabled now with the new_inference_lambda=true .hhconfig setting; this can lead to the detection of additional type errors (example below)
• string casts of Stringish objects will change to raise a runtime exception; the hhvm.notice_on_implicit_invoke_to_string option can be used to detect this.
  • this includes both explicit (string) casts, and various forms of implicit casting (e.g. concatenation, comparisons, printfs, and interpolation); searching for (string) will not find all problematic code.
• empty switch blocks ( switch ($foo) { /* empty */ }) will become a parse error.
• array() literals will be removed; use vec/dict/keyset instead if possible, otherwise varray or darray.

New lambda inference

If the type can not be inferred in a usable way, the typechecker will now raise an error instead of assuming the behavior is safe.

1
2
3
4
5
6
7
8
9
10
function just_return_it<T>((function(T): void) $f):(function(T): void) {
  return $f;
}

function break_it():void {
  // No error here
  $g = just_return_it($y ==> $y->this_method_does_not_exist());
  // Can even try and invoke it on a string
  $g('ohno');
}

HHVM 4.43 is released! This release marks the end of support for 4.36; HHVM 4.37–4.42 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• We are now building Homebrew packages for MacOS 10.15 Catalina. Please report MacOS-specific issues in the homebrew-hhvm repository.
• Extending an undefined parent class no longer produces a redundant typechecker error 4123 (“Class has a non-<?hh grandparent”), it now only produces the relevant error 2049 (“Unbound name”).
• Improved typechecker error message when attempting to declare the type of a local variable (int $x = 42;).

Breaking Changes

• Built-in functions json_decode, str_split, array_fill, class_implements, class_uses, class_parents now return darray instead of the legacy array type. This change should be largely transparent, as darray and array are interchangeable at runtime, but the change might be observable by serialize, var_dump or similar functions.
• The contains method on Set, ImmSet and ConstSet is now declared to take an arraykey argument instead of mixed. The method would already throw at runtime when called with any non-arraykey value.

HHVM 4.42 is released! This release marks the end of support for 4.35; HHVM 4.36–4.41 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• Bugs in the typechecker’s AST handling now result in error 4361, instead of an exception. This error code should never be suppressed - please file a bug report if you see this error code.
• Fix escaping of variables autocomplete snippets - e.g. Foo::bar| can now autocomplete to Foo::bar($id).
• Added HHVM_VERSION_MAJOR, HHVM_VERSION_MINOR, and HHVM_VERSION_PATCH constants; these should be used instead of parsing the HHVM_VERSION or HHVM_VERSION_ID constants. HHVM_VERSION_ID is recommended for direct comparisons, e.g. with >=.
• Added \HH\enumname<T> type to the runtime; this is similar to classname<T>, for Hack enums.
• Fixed crash in readdir() and rewinddir() if the directory is already closed; false will be returned instead.
• Improved error message for () ==> async {} (returning an async block); it now suggests async () ==> { } instead (an async lambda).

Breaking Changes

• If an interface defines a constructor, the typechecker now requires that classes that implement the interface are either abstract, or implement the constructor in accordance with the interface, matching the behavior for other methods.

Future Changes

• We will stop building any binaries for MacOS High Sierra on March 23rd, as our provider is ending support for this operating system version. We will continue to build packages for Mojave (which are usable on Catalina), and expect to begin building packages specifically for Catalina from early February.
• HHVM_VERSION_ID will change from XX.YY.ZZ to XX.YYY.ZZ, to support the expected release of HHVM 4.100 later this year; if using standard comparison operators to compare two version IDs, this should not be a significant change, unless checking for < 50000 or similar - replace that check with HHVM_VERSION_MAJOR === 4. If you’re converting to/from human-readable form, consider migrating to the new HHVM_VERSION_MAJOR, HHVM_VERSION_MINOR, and HHVM_VERSION_PATCH or existing HHVM_VERSION (string “x.y.z”) constants.
• The special behavior of ArrayAccess objects is being removed.
  • this is already a typechecker error.
  • this includes $x['foo'] for both read and write (replace with explicit offsetSet or offsetGet calls)
  • this also includes isset($x['foo']) ($x->offsetExists('foo')) and unset($x['foo']) ($x->offsetUnset('foo').
  • the hhvm.notice_on_array_access_use=true INI setting can be used to raise notices for this behavior at runtime.

HHVM 4.41 is released! This release marks the end of support for 4.34; HHVM 4.35–4.40 remain supported, as do the 4.8 and 4.32 LTS releases.

Highlights

• A new type alias, HH\enumname<TEnum>, represents the name of the enum type TEnum (similarly to classname<TClass>).
• A new function, HH\type_structure_for_alias, returns the TypeStructure of the specified type alias (similarly to HH\type_structure for type constants in classes).
  • Note that the TypeStructure API remains experimental and may be changed or removed in the future.
• Builtin functions usort, uasort, uksort now accept callbacks that return any num value (int or float), allowing for more convenient sorting of float arrays.
  • Note that these functions return legacy arrays which are deprecated. Prefer Vec\sort, Dict\sort, Keyset\sort.

Breaking Changes

• Fixed a bug that allowed XHP children declarations to contain undefined types. This may reveal many previously ignored errors.
  • XHP children declarations can now only contain defined, non-aliased, non-generic Hack types, XHP category names (%foo), and the special values pcdata, any and empty (case-sensitive).
  • Note that only the children declaration is type-checked, not the actual children where the XHP element is used. A library such as xhp-lib must be used for that.
• Typechecker errors due to assigning a value of the wrong type to an inout parameter are now reported at the location where the inout parameter is declared. This may require some HH_FIXMEs to be moved.
• Typechecker errors due to incorrect use of the argument unpacking operator (...$args) were updated to provide more information in different cases. In some cases this results in changed error numbers, but it shouldn’t result in any new errors.
• The method returnsReference was removed from ReflectionFunction and ReflectionMethod. It always returned false since HHVM no longer supports references.

HHVM 4.40 is released! This release marks the end of support for 4.33; hhvm 4.34–4.39 remain supported, as do the 4.8 and 4.32 LTS releases.

Breaking Changes

• specifying the same XHP attribute twice (<foo x="1" x="2" />) is now a syntax error

Future Changes

A change last year unintentionally made the parser accept arbitrary types for XHP children declarations, however:

• this remains unsupported by the XHP class library.
• the typechecker does not validate children.
• this can lead to impossible-to-satisfy children declarations, such as references to undefined types.

We are changing the typechecker to verify that XHP children declarations do not refer to undefined types; in the context of XHP children declarations, the following types will be considered valid by the typechecker:

• the case-sensitive special values pcdata, any, or empty.
• XHP category names, such as %foo.
• a defined, non-aliased, non-generic Hack type, such as a class name, XHP classname, or interface.

We expect this change to be included in 4.41.

There are some additional things to be aware of:

• only the declaration is validated; the typechecker will not verify that provided children actually match the declaration. This will remain a runtime-only check, which must be supported by the XHP class library.
• there are no typechecker checks for XHP categories in children declarations.
• types other than XHP class names - such as standard classes or interfaces - may not be fully supported by the XHP class library.
• type aliases are not permitted.

Additionally, this release includes disabled support for xhp class foo {} as an alternative syntax to class :foo {}; this is to unblock future work on improving interactions between XHP and namespaces - usage is not recommended at this time.

HHVM 4.39 is released! Since the 4.32 release has long term support, it remains supported, as do the 4.8 LTS and 4.33–4.38 releases.

Highlights

• Removed redundant typechecker output for some errors related to type constants (such as the second part of “Expected ClassName::T / resulting from expanding the type constant ClassName::T”).

Breaking Changes

• Improved typechecker output for errors related to mismatches between int, float, num and dynamic. In rare cases this may result in a typechecker error moving to a different location, e.g. from where a value is assigned to where it is used.
• The callback passed to set_pre_timeout_handler() must now accept a nullable wait handle argument (?Awaitable<mixed>). The wait handle will have a value when the callback is invoked right after a wait handle had finished. The wait handle is required in order to get a good backtrace. This is a similar behavior to the wait handle that is returned in the IntervalTimer class.

HHVM 4.38 is released! This release marks the end of support for 4.31; 4.32–4.36 remain supported, as does the 4.8 LTS release.

The 4.37 release was skipped due to the holiday season.

Highlights

• Added SA_RESTART to SIGVTALARM flags, allowing operations such as flock to continue when interrupted by some profiling tools, instead of failing with EINTR.
• Changed typechecker definitions of base64/url/rawurl encode/decode functions to return string, rather than untyped data. They already always returned strings in the runtime.

Breaking Changes

• building with readline now requires -DNON_DISTRIBUTABLE_BUILD=ON to be passed to cmake; editline remains supported as the default implementation, and this does not affect our builds. In custom builds, hphpd and the PHP readline-related functions may switch to using editline instead of readline.
• using assignments as an expression is now a typechecker error. This can temporarily be disabled by setting the disable_lval_as_an_expression=false .hhconfig option; this option will be removed in a future release.

We have decided to cancel next week’s release of HHVM 4.37, and expect to delay 4.38 until Thursday, the 2nd of January. HHVM 4.31 will be supported until the release of HHVM 4.38 or above. As HHVM 4.32 has long-term-support (LTS), it is unaffected by this change.

Our usual schedule is to release on Mondays or Tuesdays, and we expect many people - both at Facebook, and among our users - to be on vacation for Tuesday and Wednesday for the next two weeks. We believe that releasing new versions with breaking changes at this time would not be in the best interests of our users, especially as we would be less able to support them during this time.

We look forward to continuing the evolution of Hack and HHVM in 2020.

HHVM 4.36 is released! This release marks the end of support for 4.30; 4.31–4.35 remain supported, as does the 4.8 LTS release.

Highlights

• Statically links jemalloc 5 if the system version is older. HHVM requires 2MB-aligned 2MB allocations; older versions of jemalloc will give a 4MB allocation, leading to request OOMs. Some old versions of HHVM detected the 4MB allocation and attempted to use it, but did not do so correctly.
• Symbol search in IDEs now finds namespaced symbols again.
• Fixed the “Unbound name” typechecker error (2049) to correctly report the type of the missing entity (“an object type”, “a global function”, etc.). Previously it would incorrectly say “an object type” in most cases.

Breaking Changes

• It is now a runtime error to declare multiple constants with the same name. It had already been a typechecker error, but only a notice at runtime.
• It is now a typechecker error for a static method to use a reified generic type parameter from the encompassing class. The generic type parameter must instead be reified at the static method itself.
• Fixed a bug causing the typechecker to not report missing generic type parameters for class constants.
• Fixed incorrect typehints for some built-in sorting functions (asort, arsort, krsort, uasort, uksort). These functions may change the type of the passed-in container (e.g. vec to dict), which the original typehints didn’t account for. This change may reveal new type errors in code that uses these functions.

HHVM 4.35 is released! This release marks the end of support for 4.29; 4.30–4.34 remain supported, as does the 4.8 LTS release.

Highlights

• resolving recursive type structure now raises a fatal error, instead of HHVM infinitely recursing.
• improved error messages for unsatisfiable constructor constraints, e.g. __construct(classname<T> $f) where T = nothing.

Breaking Changes

• __halt_compiler() and __COMPILER_HALT_OFFSET__ have been removed.
• require extends T; and ... extends T {} now consistently raise naming errors (2049); previously, extend T was a naming error, while require extends T raised a type error (4026). This may require modifying FIXMEs in unsafe/invalid Hack code.
• it is no longer possible to completely disable the checking of return type hints: if hhvm.check_return_type_hints is less than 2, an E_WARNING will be raised. If set to 2, an E_RECOVERABLE_ERROR will be raised for hard type. hints, and E_WARNING for soft.
• split list and tuple destructuring errors out to new codes; this may require modifying FIXMEs (4110 to 4105 or 4357) in unsafe/invalid Hack code.

HHVM 4.34 is released! This release marks the end of support for 4.28; 4.29–4.33 remain supported, as does the 4.8 LTS release.

Highlights

• Added hh_client --concatenate-all path/ [morepaths/ ...], which creates a single-file version of a Hack project. This respects required inclusion order (e.g. parent classes before child classes), and resolves syntax issues such as namespace declarations and potentially conflicting use statements. Example usage:
  • hh_client --concatenate-all src/ for a library
  • hh_client --concatenate-all src/ vendor/ bin/foo.hack for an executable

Breaking Changes

• It is now always a type error to use self::abstractStaticMethod() to call an abstract static method inside a trait. Previously, this was only a type error if any classes used the trait without implementing the respective method. The new behavior is consistent with abstract classes, where calling self::abstractStaticMethod() was already an error. Use static::abstractStaticMethod() instead (note that this may change the behavior in some cases, but most likely the new behavior better captures the original intent of the code).
• Type errors about incorrectly overridden type constants are now reported in the child class that overrides the constant, not in the parent class that declares it. This may require some HH_FIXMEs to be moved from a parent class to its child classes.

HHVM 4.33 is released! This release marks the end of support for 4.27; 4.28–4.32 remain supported, as does the 4.8 LTS release.

Highlights

• For developers working on the implementation of Hack itself (in rust/ocaml):
  • the test suite now passes in open source builds
  • the code generation tools for updating the parser and rust/ocaml FFI are now usable in opensource builds

Breaking Changes

• Fixed issue where some FIXMEs had no effect on the code they were attached to instead having action-at-a-distance. This could lead to errors being reported in the wrong file. This bugfix may require fixmes to be added or moved.
• An error is now raised if a reified function call is made without all required generics; for example, foo<vec>() now raises an error, as vec requires a generic type
• Type structures for type aliases are now keyed by opaqueness and the alias name. In previous versions, if multiple types/type aliases resolved to the same concrete type, the wrong type structure would sometimes be returned - for example, with newtype FOO = int;, it was previously unpredicable if the type stucture for new MyClass<FOO>() would return the type alias information or not, and new MyClass<int>() could return FOO’s type alias information. The correct type structure will now consistently be returned. This only affects classes with reified generics - functions using reified generics are unaffected

HHVM 4.32 is released! This release has long term support, so:

• this release will be supported for approximately 48 weeks
• the next LTS will be released in approximately 24 weeks
• HHVM 4.8 and HHVM 4.27–4.31 remain supported
• support ends for HHVM 3.30, the last HHVM release compatible with PHP

See also the new support lifecycle for older distributions.

Highlights

• Fixed an issue where some built-in functions, available at runtime, were not recognized by the typechecker (e.g. fb_intercept2, fb_serialize, xhprof_enable). See header file for the full list.
• For developers: You can now use source $BUILD/hphp/hack/dev_env.sh to set up the correct environment for all OCaml tools (dune/cargo/opam/ocamlformat/…).
• The HTTP server bundled with HHVM (Proxygen) now allows the MOVE method.
• The type varray_or_darray (a helper type, only existing in the typechecker, for migrating from legacy arrays) now has two generic type parameters.
  • For backwards compatibility, it can still be used with a single generic type parameter, where varray_or_darray<T> is implied to mean varray_or_darray<arraykey, T>.
  • See recently updated guide for more information about legacy array migration types.

Breaking Changes

• All types that can be iterated with foreach now extend a single Traversable interface.
  • Fully qualified name is \HH\Traversable, but since this is an “autoimported” type, the fully qualified name should never be needed.
  • Previously, there were two separate interfaces, \Traversable and \HH\Traversable, with most (but not all!) types implementing \HH\Traversable (an example exception is DOMNodeList which only implemented \Traversable).
  • The \Traversable and \Iterator interfaces (inherited from PHP) have been removed in favor of \HH\Traversable and \HH\Iterator. Hack code that refers to Traversable and Iterator with no leading backslash will continue to work unchanged, but code that had \Traversable or \Iterator needs to either remove the leading backslash or add \HH (note that this changes the behavior of the affected code, making it refer to a much larger set of iterable types).
• Using HH\BuiltinEnum outside of built-in header files is once again disallowed by the typechecker (error 2053). This restriction had recently been lifted (in HHVM 4.28), but it is being reintroduced because we discovered some new runtime issues when the type is used.
• The runtime config option hhvm.php7.int_semantics has been removed.

We currently package for Debian 8 (Jessie) from 2015, and Ubuntu 16.04; this constrains us in several ways, such as:

• supporting building with older system libraries, especially OpenSSL 1.0 (1.1+ includes many breaking changes)
• supporting older GCC versions, runtimes, and C++ ABIs
• maintaining internal test infrastructure for these old distributions

To allow more time to be spent on improving Hack itself, in the future, we will be more aggressive about removing support for older distributions.

HHVM 4.32 - due to be announced later today - will be an LTS release; 4.56 will be the next LTS release, and is due in 24 weeks (week of 2020-05-04). 4.56 will be the last release that supports:

• MacOS Mojave
• Debian 8 Jessie
• Debian 9 Stretch
• Ubuntu 16.04

In HHVM 4.57 and above, we will aim to support:

• MacOS: the latest stable release (currently Catalina). If the release has been stable for less than 6 months, we will also aim to support the previous stable version (currently Mojave)
• Debian: stable (currently Buster). If the current stable was released in the last 6 months, we will also aim to support oldstable (currently Stretch). We are open to investigating support for Debian testing (currently Bullseye), but are not currently doing so.
• Ubuntu:
  • the current LTS release (18.04); if the LTS is less than 6 months old, the previous LTS will also be supported
  • non-LTS (‘interim’) releases will be supported for 9 months from their release; this matches the length of time that they are supported by Canonical

What ending support means

In general, we do not intend to proactively stop testing/packaging for distributions as soon as they become ‘unsupported’; however:

• when we want to upgrade our internal test infrastructure or update the minimum versions of our dependencies, the versions provided by unsupported distributions will not be a factor in that decision
• if our packaging starts failing on supported distributions, we may stop building for them instead of fixing it

Given we want to remove support for OpenSSL 1.0 and for systems using the C++5 ABI, we expect to stop building packages for several distributions - especially Debian 8 Jessie and Ubuntu 16.04 very shortly after the release of HHVM 4.56.

Bugfix and security updates

If we build a package for a distribution for a x.y.0 release, we intend to build packages for that distribution for any x.y.z releases - as long as the distribution itself continues to receive security updates from the distribution vendor.

In other words, dropping support for a distribution in a new release does not affect support for that distribution in past verisons of HHVM.

For example:

• 4.56.0 will support Debian 8 Jessie and Ubuntu 16.04
• if a 4.56.1 release is made mid-June 2020, it would still support Debian 8 and Ubuntu 16.04 - even if 4.57 has been released without support for those distributions
• if a 4.56.2 release is made in July 2020, it would still support Ubuntu 16.04, but it would not support Debian 8, as Debian 8 reaches end of life on June 30th, 2020

Using unsupported distributions

We strongly recommend using a supported distribution instead. That said, there are several options:

• run HHVM via Docker or other containerization techniques
• install/build updated versions of any required dependencies (likely to include GCC and OpenSSL), then build/package HHVM yourself
• send pull requests to fix builds on unsupported distributions - though we will not accept pull requests that increase the burden on developers; for example, once folly drops support for OpenSSL 1.0, we will not accept pull requests that re-add it

If you are using a current version of a distribution that we do not package for at all (e.g. CentOS), we would appreciate pull requests to add support to our packaging infrastructure; any new packaging should be:

• reproducible. For example, fetching master of a dependency from github is not acceptable
• following the distribution’s best practices for packaging as much as possible. For example, this could mean using rpmbuild or debuild or similiar instead of manually building a package from binaries created separately

The HHVM support lifecycle for any other distributions would likely be similar to our support lifecycle for Debian and Ubuntu, aiming to provide some upgrade window while allowing us to frequently update the minimum versions of dependencies.

HHVM 4.31 is released! This release marks the end of support for 4.25; 4.26–4.30 remain supported, as do the LTS releases 3.30 and 4.8.

Highlights

• Added new HH\Lib\SQL\Query object, and AsyncMysqlConnection::queryAsync() method; this is an alternative to ::queryf(). Query objects:
  • are constructed with a queryf-style format string and a list of parameters
  • accept vec<>s instead of Vector<>s
  • add support for the %Q placeholder, which accepts another Query object; this allows much more flexibility, such as concatenating queries with $ab = new Query('%Q %Q', $a, $b)
• Fixed incorrect ‘out of memory’ errors in hh_server when posix_fallocate fails with EINTR

Breaking Changes

• Removed typechecker special-casing of HH\Tuple\from_async() and HH\Asio\va(); ideally, these should be replaced with concurrent blocks, or, if a tuple is actually desired, tuple(await foo(), await bar()) can be used instead
• Removed HH\Asio\va()’s typechecker definition as it is no longer useful
• ldap_mod_(del|replace|modify) now take a darray entry argument
• the (unset) cast has been removed. Use the null literal instead
• unserialize()ing a PHP array will now create a varray or darray

HHVM 4.30 is released! This release marks the end of support for 4.24; 4.25–4.29 remain supported, as do the LTS releases 3.30 and 4.8.

Highlights

• fixed handling of parsing errors in the mailparse extension (issue #8532)
• the typechecker now considers most built-in “auto-imported” types to be in the HH namespace (HH\dict, HH\Container, etc.), consistently with how the runtime already treated them
  • previously, the typechecker incorrectly considered them to belong to the root namespace, so this fixes cases where the typechecker would report errors in correct code (HH\dict), or not report errors in code that would fail at runtime (\dict)
  • that said, as these types are auto-imported, it is never necessary, and not recommended, to refer to them using their fully qualified names (use dict instead of HH\dict, etc.)
  • specific types fixed in the current release: vec, dict, keyset, Container, KeyedContainer, Traversable, KeyedTraversable, Iterable, KeyedIterable, Iterator, KeyedIterator, AsyncIterator, AsyncKeyedIterator, AsyncGenerator

Breaking changes

• it is no longer possible to override built-in types using use statements (use MyVector as Vector, use MyType as string, etc.)
• fixed a few remaining places where built-in types were still treated as case-insensitive (should not affect most users, as they were already treated as case-sensitive almost everywhere)

Future changes

• we are starting to work on deprecating PHP-style anonymous functions (function($num) { return $num * 2; }) in favor of lambdas ($num ==> $num * 2)
  • you can test this by adding error_php_lambdas=true to your .hhconfig (this will likely become the default behavior in the future)
• we are working on extending fb_serialize() to correctly distinguish between all the different array-like types (vec, dict, keyset, varray, darray, array)
  • these changes should be backwards compatible, generally hidden behind new flags

HHVM 4.29 is released! This release marks the end of support for 4.23; 4.24–4.28 remain supported, as do the LTS releases 3.30 and 4.8.

Highlights

• Error messages now strip HH\ from names that are automatically imported into every namespace
• Fixed .hack files not being correctly indexed by some IDE features
• Shape key autocomplete now detects pre-existing quotes, avoiding completions such as $someshape['somekey''] with two apostrophes; this was most common with IDEs configured to automatically insert matching quotation marks.
• Added RuntimeOption::CheckIntOverflow option:
  • if 0 (the default), overflows will silently wrap; this setting has the best performance
  • if 1, overflows will wrap and warn
  • if 2, overflows will throw an exception
• Autocomplete now downranks magic methods and functions/methods with DO_NOT_USE in the name

Breaking Changes

• $c->toVector(), $c->toSet(), $c->toMap() have been removed from Hack collections; use new Vector($c) etc or Hack Arrays instead; this is because they are not type-safe, as variance checks were added for generics
• auto-imported reserved names (e.g. ‘self’) are now case-sensitive at runtime
• Set::zip() now returns Set<nothing>, as pairs can not be stored in Sets; this could lead to new type errors in code that would previously fail at runtime. Similar changes have been made to ImmSet and other related classes
• unserialize() no longer creates references; if old serialized data containing references is used, the referenced value will be copied instead
• references are no longer supported by the parser
• the runtime and typechecker now agree that Awaitable’s fully-qualified name is HH\Awaitable; it remains autoimported. In previous releases, the runtime considered it to be HH\Awaitable, but the typechecker considered it to be \Awaitable
• it is now an error to pass a superglobal as inout
• array (without generics) is now considered to be the union of array<_> (a.k.a varray) and array<_, _> (a.k.a. darray); this can lead to stricter handling of key (example 1, example 2)

A security update has been released for all supported HHVM versions. Please update to one of the following versions to make sure you’re secure:

• 4.28.2
• 4.27.1
• 4.26.1
• 4.25.1
• 4.24.1
• 4.23.2
• 4.8.6
• 3.30.12

This security update addresses multiple potential vulnerabilies, mostly found by running a new fuzzer over the HHVM codebase.

More information can be found in the respective CVEs: