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.