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.
Improve the text stylistically and grammatically. Rewrite intro to nudge
people into the right direction and warn them about the usual fate of
spontaneous PRs.
The files were not really templates but instructions. These instructions
are already spelled-out in CONTRIBUTING.md and repeating them feels a
bit redundant.
If it turns out people don't read CONTRIBUTING.md when submitting issues
and pull requests, I'll probably restore the templates (likely in some
shorter/simpler form).
Until now, expectations were constructed using object literals. This
commit changes the construction to use factory functions.
This change makes generated parsers slightly smaller because property
names don't have to be repeated many times and factory function calls
are more amenable to minifying.
Some numbers based on the aggregate size of parsers generated from
examples/*.pegjs:
Optimization Minified? Size before Size after Saving
------------------------------------------------------------
speed no 719066 716063 0.42%
speed yes 188998 180202 4.65%
size no 194810 197813 1.52%
size yes 108782 99947 8.12%
(Minification was done using "uglify --mangle --compress" with
uglify-js 2.4.24.)
The "buildMessage" utility function, which was previously internal, is
now exposed as SyntaxError.buildMessage in generated parsers.
The motivation behind this is two-fold:
1. Building of a syntax error message is a responsibility of the
SyntaxError class, meaning the code should be placed there.
2. By exposing the message building code, parser users can use it to
generate customized error messages without duplicating PEG.js's code.
Note that helper functions inside "buildMessage" ("describeExpected",
"describeFound", etc.) currently aren't exposed. They may become exposed
in the future if there is enough demand.
David Majda