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.
The "parser" variable allowed access to the parser object. Among other
things, this made it possible to invoke the parser recursively using
"parser.parse".
One problem with the "parser" variable is that it bakes in the idea that
the parser is an *object*, not a *module*. While this is true now, it
won't necessarily be in the future, when parsers may be exported as ES6
modules. Also, people tend to use parsers as modules even today, e.g.
like this:
var parse = require("parser").parse;
var result = parse(...);
Such usage broke the "parser" variable (as it was implemented).
For this reasons I decided to remove the "parser" variable. If someone
needs to do tricks like recursive invocation of the parser, he/she must
pass the parser or the "parse" function itself using options.
Related to #433.
This change makes it possible to use "generate" as a module function,
e.g. like this:
var generate = require("pegjs").generate;
var parser = generate(...);
Fixes#433.
This is more traditional compiler interface. Its main advantage against
specifying the output file as a second argument (which is what bin/pegjs
used until now) is that input and output files can't be mixed up.
Part of #370.
This will make room for -o to mean --output instead of --optimize. Also,
-O is more traditional option name for describing optimization config
than -o.
Part of #370.
David Majda