To distinguish array() and [] syntax. The pretty printer respects
this attribute. The shortArraySyntax pretty printer option acts as
a default in case the attribute is not specified.
Kind specifies whether the number was formatted as decimal, octal,
binary or hex. The pretty printer reproduces the number kind (but
not necessarily the exact formatting).
A Nop statement will be inserted into statement lists if there are
any trailing comments in the list (which would otherwise not be
associated with any node).
The pretty printer output currently still contains a superfluous
newline.
We can't strip the <?php at the end of a __halt_compiler() segment
in file mode.
Fixed by being a bit more explicit in prettyPrintFile() about what
we want to do...
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.
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.
Previously the pretty printer added unnecessary and odd-looking parentheses
when several operators with the same precedence were chained:
'a' . 'b' . 'c' . 'd' . 'e'
// was printed as
'a' . ('b' . ('c' . ('d' . 'e')))
Another issue reported as part of #39 was that assignments inside closures
were wrapped in parentheses:
function() {
$a = $b;
}
// was printed as
function() {
($a = $b);
}
This was caused by the automatic precedence handling, which just regarded
the closure as an ordinal nested expression.
With the new system the $predenceMap of PrettyPrinterAbstract contains both
precedence and associativity and there is a new method pPrec() which prints
a node taking precedence and associativity into account.
For simpler usage there are additional function pInfixOp(), pPrefixOp() and
pPostfixOp().
Prints not going through pPrec() do not have any precedence handling (fixing
the closure issue).
