1029 Commits (b5bd30c813fccd674995c3f61f843162236a076c)
 

Author SHA1 Message Date
David Majda 0a2217d3da bin/pegjs: Order options in a switch statement alphabetically 9 years ago
David Majda ff330a0d4b bin/pegjs: Order options in help text alphabetically 9 years ago
David Majda a57431955e bin/pegjs: Use the -o/--output option to specify the output file
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.
9 years ago
David Majda 9bf7c0c5ff bin/pegjs: Remove detailed instructions from the help text
They don't belong there.

Part of #370.
9 years ago
David Majda 35b3971366 bin/pegjs: Rename the -o option to -O
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.
9 years ago
David Majda 1c14a2c8f2 bin/pegjs: Allow using "-" to mean standard input and output
Part of #370.
9 years ago
David Majda 6eb42ddae7 Update CONTRIBUTING.md
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.
9 years ago
David Majda b10ddc4877 Move .github/CONTRIBUTING.md to CONTRIBUTING.md
No need to have a .github directory for just one file.
9 years ago
David Majda 3db71ebceb Remove .github/{ISSUE,PULL_REQUEST}_TEMPLATE
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).
9 years ago
David Majda 930877c3ba Move lib/compiler.js to lib/compiler/index.js
This makes "compiler" a regular Node.js module.
9 years ago
David Majda 5a4d04fa90 Construct expectations using functions
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.)
9 years ago
David Majda e7d03825e0 AST: Remove the "rawText" property from "class" nodes
It isn't used anymore.
9 years ago
David Majda 35c8280743 Expectation refactoring 7/7: Regenerate lib/parser.js 9 years ago
David Majda 8639cf6d61 Expectation refactoring 6/7: Move "buildMessage" to SyntaxError
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.
9 years ago
David Majda 999cc7be74 Expectation refactoring 5/7: Refactor "buildMesage"
Mostly just extract few functions, increasing readability.
9 years ago
David Majda 319931876d Expectation refactoring 4/7: Generate descriptions dynamically
Instead of pre-generating expectation descriptions when generating
parsers, generate them dynamically from structured information contained
in the expectations.

This change makes descriptions a presentation-only concept. It also
makes generated parsers smaller.
9 years ago
David Majda 22cb123479 Expectation refactoring 3/7: Change expectation processing
Before this commit, expectations were sorted and de-duplicated before
they were passed to "buildMessage" and exposed in the "expected"
property of syntax errors. This commit moves this processing into
"buildMessage" and rewrites it to process only expectation descriptions.
This means expectations exposed in the "expected" property are "raw"
(not sorted and de-duplicated).

This change will allow us to get rid of the "description" property of
expectations and compute descriptions dynamically from structured
information in the expectations. This will make descriptions a
presentation-only concept. It will also make generated parsers smaller.

Note that to keep expectations in the "expected" property sorted even
without the "description" property, some sorting scheme based on
structured information in the expectations would have to be devised,
which would complicate things with only a little benefit. Therefore I
chose to keep the expectations there "raw".
9 years ago
David Majda c6e8c53f1b Expectation refactoring 2/7: Restructure "class" expectations
Changes:

  * Remove the "value" property (it is replaced by other properties).

  * Add the "parts", "inverted", and "ignoreCase" properties (which
    allow more structured access to expectation data).
9 years ago
David Majda eda2a34c7f Expectation refactoring 1/7: Restructure "literal" expectations
Changes:

  * Rename the "value" property to "text" (because it doesn't contain
    the whole value, which also includes the case sensitivity flag).

  * Add the "ignoreCase" property (which was missing).
9 years ago
David Majda d48983dd6a Don't use the "i" suffix for case-insensitive class descriptions
If the described class is case-sensitive, nothing changes.

If the described class is case-insensitive, its description doesn't
indicate that anymore. The indication was awkward and it was meaningful
only for parser users familiar with PEG.js grammar syntax (typically a
minority). For cases where case insensitivity indication is vital, named
rules can be used to customize the reporting.

Note that literal descriptions already ignore the case-sensitivity flag;
this commit only makes things consistent.
9 years ago
David Majda b2d7f9e02f Fix comment typo 9 years ago
David Majda d73a5208a0 Simplify various escaping functions
Simplify regexps that specify ranges of characters to escape with "\xXX"
and "\uXXXX" in various escaping functions. Until now, these regexps
were (mostly) mutually exclusive with more selective regexps applied
before them, but this became a maintenance headache. I decided to
abandon the exclusivity, which allowed to simplify these regexps (at the
cost of introducing an ordering dependency).
9 years ago
David Majda b31436d778 Escape also DEL (U+007F) when generating JavaScript strings & regexps
It is a control character.
9 years ago
David Majda 1f7efd57c0 Remove various JSHint-related cruft
We use ESLint now, which is smarter about some things.
9 years ago
David Majda 75cedcb7d8 Harmonize found string escaping with expectation escaping
Change how found strings are escaped when building syntax error
messages:

  * Do not escape non-ASCII characters (U+0100-U+FFFF). They are
    typically more readable in their raw form.

  * Escape DEL (U+007F). It is a control character.

  * Escape NUL (U+0000) as "\0", not "\x00".

  * Do not use less known shortcut escape sequences ("\b", "\f"), only the
    well-known ones ("\0", "\t", "\n", "\r").

These changes mirror expectation escaping changes done in
4fe682794d.

Part of work on #428.
9 years ago
David Majda 6b60896216 Revert "Remove info about found string from syntax errors"
This reverts commit 25ab98027d.

Part of work on #428.
9 years ago
David Majda 4fe682794d Improve expression descriptions in error messages
Before this commit, descriptions of literals used in error messages were
built by applying JavaScript string escaping to their values, making the
descriptions look like JavaScript strings. Descriptions of character
classes were built using their raw text. These approaches were mutually
inconsistent and lead to descriptions which were over-escaped and not
necessarily human-friendly (in case of literals) or coupled with details
of the grammar (in case of character classes).

This commit changes description building code in both cases and unifies
it. The intent is to generate human-friendly descriptions of matched
expressions which are clean, unambiguous, and which don't escape too
many characters, while handling special characters such as newlines
well.

Fixes #127.
9 years ago
David Majda 2fd77b96fc Revert "Use literal raw text in error messages"
I no longer think that using raw literal texts in error messages is the
right thing to do. The main reason is that it couples error messages
with details of the grammar such as use of single or double quotes in
literals. A better solution is coming in the next commit.

This reverts commit 69a0f769fc.
9 years ago
David Majda c50ad15461 Use http-server to serve specs and benchmarks to the browser
Previously, the instructions recommended using Python's SimpleHTTPServer
module, which created unnecessary dependency on Python.
9 years ago
David Majda 138405d89d Add syntax highlighting to code blocks in README.md files 9 years ago
David Majda 45de51a881 Consistently talk about generating (not building) a parser 9 years ago
David Majda f4504a93fe Rename the "buildParser" function to "generate"
In most places, we talk about "generating a parser", not "building a
parser", which the function name should reflect. Also, mentioning a
parser in the name is not necessary as in case of a parser generator
it's pretty clear what is generated.
9 years ago
David Majda 0847a69643 Rename the "PEG" variable to "peg"
So far, PEG.js was exported in a "PEG" global variable when no module
loader was detected. The same variable name was also conventionally used
when requiring it in Node.js or otherwise referring to it. This was
reflected in various places in the code, documentation, examples, etc.

This commit changes the variable name to "peg" and fixes all relevant
occurrences. The main reason for the change is that in Node.js, modules
are generally referred to by lower-case variable names, so "PEG" was
sticking out when used in Node.js projects.
9 years ago
David Majda 057a93fbc7 Move the "Generated by ..." comment out of wrapping functions
The wrapping functions are also generated by PEG.js, so the comment
should be above them to mark them as such. This shouldn't cause any
problems technically.
9 years ago
David Majda f934199fba Simplify code which generates parser wrappers 9 years ago
David Majda f390c7cf45 ESLint: Disable no-console in bin/.eslintrc.json, not bin/pegjs
The less clutter in JavaScript files themselves, the better.
9 years ago
David Majda 810567d865 UMD parsers: Allow specifying parser dependencies
Introduce two ways of specifying parser dependencies: the "dependencies"
option of PEG.buildParser and the -d/--dependency CLI option. Specified
dependencies are translated into AMD dependencies and Node.js's
"require" calls when generating an UMD parser.

Part of work on #362.
9 years ago
David Majda fe6ce38d08 UMD parsers: Regenerate lib/parser.js
Part of work on #362.
9 years ago
David Majda a0a57cd22d UMD parsers: Make bin/pegjs generate UMD parsers
Part of work on #362.
9 years ago
David Majda b87268ade6 UMD parsers: Allow generating parsers in UMD format from the API
Introduce new "format" and "exportVar" options to PEG.buildParser which
together allow generating parsers in UMD format.

Part of work on #362.
9 years ago
David Majda ab0e85b006 UMD parsers: Refactor "generateWrapper"
Extract "generateWrapper" code which generates code of the intro and the
returned parser object into helper functions. This is pure refactoring,
generated parser code is exactly the same as before.

This change will make it easier to modifiy "generateWrapper" to produce
UMD modules.

Part of work on #362.
9 years ago
David Majda 7f8b3f7012 UMD parsers: Generate parser wrapper separately from its toplevel code
Code which was at the toplevel of the "generateJS" function in the code
generator is now split into "generateToplevel" (which genreates parser
toplevel code) and "generateWrapper" (which generates a wrapper around
it). This is pure refactoring, generated parser code is exactly the same
as before.

This change will make it easier to modifiy the code genreator to produce
UMD modules.

Part of work on #362.
9 years ago
David Majda 5e702b5901 lib/compiler.js: Fix indentation 9 years ago
David Majda a89aa11779 README.md: Mention that AMD loader will be used in the browser 9 years ago
David Majda ce44c62f14 Support passing custom location info to "error" and "expected"
Based on a pull request by Konstantin (@YemSalat):

  https://github.com/pegjs/pegjs/pull/391

Resolves #390.
9 years ago
David Majda da2378d887 Rewrite handling of optional parameters
Instead of testing arguments.length to see whether an optional parameter
was passed to a function, compare its value to "undefined". This
approach has two advantages:

  * It is in line with handling of default parameters in ES6.

  * Optional parameters are actually spelled out in the parameter
    list.

There is also one important disadvantage, namely that it's impossible to
pass "undefined" as an optional parameter value. This required a small
change in two tests.

Additional notes:

  * Default parameter values are set in assignments immediately
    after the function header. This reflects the fact that these
    assignments really belong to the parameter list (which is where they
    are in ES6).

  * Parameter values are checked against "void 0" in places where
    "undefined" can potentially be redefiend.
9 years ago
David Majda f866712c90 Regularize Jasmine custom matcher signatures
The "toParse" matcher in generated-parser-behavior.spec.js effectively
had these signatures:

  toParse(input)
  toParse(input, expected)
  toParse(input, options, expected)

This commit regularizes them to:

  toParse(input)
  toParse(input, expected)
  toParse(input, expected, options)

Similarly, the "toFailToParse" matcher in
generated-parser-behavior.spec.js effectively had these signatures:

  toFailToParse(input)
  toFailToParse(input, details)
  toFailToParse(input, options, details)

This commit regularizes them to:

  toFailToParse(input)
  toFailToParse(input, details)
  toFailToParse(input, details, options)

Finally, the "toChangeAST" matcher in helpers.js effectively had these
signatures:

  toChangeAST(grammar, details)
  toChangeAST(grammar, options, details)

This commit regularizes them to:

  toChangeAST(grammar, details)
  toChangeAST(grammar, details, options)

The overall purpose of these changes is to avoid different parameters
appearing at the same position, which is hard to manage without using
"arguments".
9 years ago
David Majda 7089debae2 .travis.yml: Test also with Node.js 6.0.x 9 years ago
David Majda 0c39f1cf86 Fix labels leaking to outer scope
Labels in expressions like "(a:"a")" or "(a:"a" b:"b" c:"c")" were
visible to the outside despite being wrapped in parens. This commit
makes them invisible, as they should be.

Note this required introduction of a new "group" AST node, whose purpose
is purely to provide label scope isolation. This was necessary because
"label" and "sequence" nodes don't (and can't!) provide this isolation
themselves.

Part of a fix of #396.
9 years ago
David Majda 58806a3d77 Label scope specs: Add negative specs (subexpressions)
Semantic predicate and action specs which verified label scope didn't
exercise labels in subexpressions. This commit adds cases exercising
them, including few commented-out cases which reveal #396 (these will be
uncommented when the bug gets fixed).

Note that added specs exercise all relevant expression types. This is
needed because code that makes subexpression labels invisible to the
outside is separate for each expression type so one generic test
wouldn't generate enough coverage.

Part of a fix of #396.
9 years ago