HHVM 4.62 is released! HHVM 4.57–4.61 remain supported, as do the 4.32 and 4.56 LTS releases.
json_decode_with_error(), which take a new
inout ?(int, string) $errorparameter as their second argument, instead of mutating global state (which would be retrievable via
- 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
- 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 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
allowed_fixme_codes_strict=1234,5678: FIXME codes that are permitted in all other files, including
.phpfiles starting with
<?hh // partial. We still recommend moving to
.hackpartialfiles, and expect support for
// partialto 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
_partialoptions 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
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