This will allow to use ES2015 constructs in spec code.
The change required introducing a small server, which serves both PEG.js
and spec code passed through Babel and bundled together. This allowed to
convert the specs to regular modules and get rid of the hackery that was
previously needed to make them run both in Node.js and in the browser.
Note the specs no longer exercise the browser version. This will allow
to spec PEG.js internals in the future.
See #442.
The buildLogicalExpression function was defined, but not used;
specifically, the Logical(AND|OR)Expression(NoIn)? rules were
constructing BinaryExpression nodes, but are now LogicalExpression
nodes as per the ESTree spec (es5.md).
The JavaScript example grammar's VariableDeclaration nodes were missing
the "kind" member (which is always set to "var", according to the
ESTree spec).
Parsers generated in this format use module.exports, so they are not
strictly CommonJS, but this is a common extension and the original name
would be confusing once Node.js implements ES2015 modules.
Note the update required disabling the "no-control-regex" rule, which
started reporting following errors:
/Users/dmajda/Programming/PEG.js/pegjs/lib/compiler/js.js
22:16 error Unexpected control character in regular expression no-control-regex
27:16 error Unexpected control character in regular expression no-control-regex
28:16 error Unexpected control character in regular expression no-control-regex
51:16 error Unexpected control character in regular expression no-control-regex
52:16 error Unexpected control character in regular expression no-control-regex
/Users/dmajda/Programming/PEG.js/pegjs/lib/parser.js
76:16 error Unexpected control character in regular expression no-control-regex
77:16 error Unexpected control character in regular expression no-control-regex
90:16 error Unexpected control character in regular expression no-control-regex
91:16 error Unexpected control character in regular expression no-control-regex
Rename compiler passes as follows:
reportLeftRecursion -> reportInfiniteRecursion
reportInfiniteLoops -> reportInfiniteRepetition
This reflects the fact that both passes detect different ways of causing
the same problem (possible infinite loop when parsing).
The new terminology is more precise and in line with commonly used
programming languages.
The change involves mainly renaming related compiler pass and files
associated with it.
This change reflects the fact that PEG.js-generated parsers really
produce two kinds of syntax errors:
Structured errors
Caused by match failures, trailing input, or calls of the "expected"
function in parser code. Their messages have fixed format ("Expected
... but ... found.").
Simple errors
Caused by calls of the "error" function in parser code. Their
messages don't have any fixed format.
Each kind of error now has a separate helper function which builds its
instances.
David Majda
Ali Tavakoli