HipHop Virtual Machine for PHP

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] 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[]; 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. [Less]

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 ... [More] , 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 avaiable, 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 The %{euid} and %{schema} placeholders are optional, and if present, automatically replaced with the current effective user ID and HHVM schema version - when there are incompatible changes to HHVM, the schema should change and a new file should be used. 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 [Less]

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 ... [More] , 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 avaiable, 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 [Less]

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 ... [More] 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). [Less]

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 ... [More] 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. [Less]

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 ... [More] 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 No Progress - Allowed by both the Type Checker and runtime. Lints may exist. Enforced By Type Checker - the Type checker will report errors Soft Runtime Enforcement - Violations may trigger logs via the runtime, configurable via flag. Hard Runtime Enforcement - Violations will produce a runtime exception 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. [Less]

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 ... [More] 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. [Less]

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 ... [More] update addresses the following vulnerabilities: possible crash (null pointer dereference) in mailparse_rfc822_parse_addresses() “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 [Less]

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 ... [More] 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 [Less]

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 ... [More] 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 overriden 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() [Less]