This should be enough for all cases, because: A double has 53 bits
of mantissa (including the implicit 1 bit), which is 53*ln(2)/ln(10)
= 15.95 decimal digits. However the leading decimal digit may encode
less than the usual 3.32 bits, which will push this over the edge to
requiring 17 decimal digits.
Adding only a single recovery rule for now.
The API is now:
* throwOnError parser option must be disabled.
* List of Errors is available through $parser->getErrors(). This
method is available either way.
* If no recovery is possible $parser->parse() will return null.
(Obviously only if throwOnError is disabled).
Were this library to be fully annotated with scalar types and
return types where possible and were strict types to be enabled
for all files, the test suite would now pass.
This adds an additional "returnType" subnode to Stmt\Function_,
Stmt\ClassMethod and Expr\Closure, as well as the corresponding
support in the name resolver and pretty printer.
Instead of storing subnodes in a subNodes dictionary, they are
now stored as simple properties. This requires declarating the
properties, assigning them in the constructor, overriding
the getSubNodeNames() method and passing NULL to the first argument
of the NodeAbstract constructor.
[Deprecated: It's still possible to use the old mode of operation
for custom nodes by passing an array of subnodes to the constructor.]
The only behavior difference this should cause is that getSubNodeNames()
will always return the original subnode names and skip any additional
properties that were dynamically added. E.g. this means that the
"namespacedName" node added by the NameResolver visitor is not treated
as a subnode, but as a dynamic property instead.
This change improves performance and memory usage.
HHVM does not throw warnings from token_get_all()
for invalid chars and unterminated comments. This
is not really integral functionality, so I'm okay
to just skip it to get a passing HHVM build.
When parsing on PHP 7 we will no longer be able to deal with
code that contains invalid octal literals. Currently we'll fatal,
after engine exceptions land we'll throw an exception instead.
While array (with name components) could technically be allowed (as
they are supported by the Name node itself), more likely than not
an array would due to incorrect usage of the API (e.g. array instead
of variadics).
