867 Commits (35c8280743216b06e37eddce8df3f804ad5e6430)
 

Author SHA1 Message Date
David Majda 35c8280743 Expectation refactoring 7/7: Regenerate lib/parser.js 8 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.
8 years ago
David Majda 999cc7be74 Expectation refactoring 5/7: Refactor "buildMesage"
Mostly just extract few functions, increasing readability.
8 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.
8 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".
8 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).
8 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).
8 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.
8 years ago
David Majda b2d7f9e02f Fix comment typo 8 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).
8 years ago
David Majda b31436d778 Escape also DEL (U+007F) when generating JavaScript strings & regexps
It is a control character.
8 years ago
David Majda 1f7efd57c0 Remove various JSHint-related cruft
We use ESLint now, which is smarter about some things.
8 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.
8 years ago
David Majda 6b60896216 Revert "Remove info about found string from syntax errors"
This reverts commit 25ab98027d.

Part of work on #428.
8 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.
8 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.
8 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.
8 years ago
David Majda 138405d89d Add syntax highlighting to code blocks in README.md files 8 years ago
David Majda 45de51a881 Consistently talk about generating (not building) a parser 8 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.
8 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.
8 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.
8 years ago
David Majda f934199fba Simplify code which generates parser wrappers 8 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.
8 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.
8 years ago
David Majda fe6ce38d08 UMD parsers: Regenerate lib/parser.js
Part of work on #362.
8 years ago
David Majda a0a57cd22d UMD parsers: Make bin/pegjs generate UMD parsers
Part of work on #362.
8 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.
8 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.
8 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.
8 years ago
David Majda 5e702b5901 lib/compiler.js: Fix indentation 8 years ago
David Majda a89aa11779 README.md: Mention that AMD loader will be used in the browser 8 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.
8 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.
8 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".
8 years ago
David Majda 7089debae2 .travis.yml: Test also with Node.js 6.0.x 8 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.
8 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.
8 years ago
David Majda ffd90a8c9e Label scope specs: Add negative specs (sequences)
So far, semantic predicate and action specs which verified scope of
labels from containing or outer sequences exercised only cases where
label variables were defined. This commit adds also some negative cases.

The idea comes from @Mingun.
8 years ago
David Majda 7229318671 Label scope specs: Don't exercise all expression types
Semantic predicate and action specs which verified scope of labels from
outer sequences exercised all relevant expression types. This is not
needed as the behavior is common for all expression types and no extra
code needs to be written to make it work for each of them.

This commit changes the specs to verify scope of labels from outer
sequences using only one expression type.
8 years ago
David Majda a20d04edf4 Label scope specs: Remove redundant sequence elements
Semantic predicate specs which verified scope of labels from containing
sequences used 3 elements where 1 is enough.

This commit removes the redundant elements.
8 years ago
David Majda 6bc91c010d Label scope specs: Tweak spec descriptions 8 years ago
David Majda 921f1fa8fa Label scope specs: Tweak suite descriptions 8 years ago
David Majda 5c5f79519a Label scope specs: Simplify semantic predicate and action specs
Semantic predicate and action specs which verified label scope used
repetitive "it" blocks. Rewrite them to use just one "it" block and a
list of testcases. This makes them more concise.
8 years ago
David Majda 31e7147081 Label scope specs: No result checks in semantic predicate specs
Semantic predicate specs which verified label scope also checked parser
results. This is not necessary because for the purpose of these specs it
is enough to verify that label variables have correct values, which is
done in predicate code already.

This commit removes parser result checks from these specs.
8 years ago
David Majda f07ab7f32e examples/json.pegjs: Fix the "unescaped" rule
The "unescaped" rule was created by mechanically translating original
RFC 7159 rule:

  unescaped = %x20-21 / %x23-5B / %x5D-10FFFF

into:

  unescaped = [\x20-\x21\x23-\x5B\x5D-\u10FFFF]

However, this mechanical translation was incorrect as PEG.js grammars
don't have 6-digit Unicode escape sequences. Sequence "\u10FFFF" was
interpreted as "\u10FF" followed by two "F" characters.

This commit rewrites the "unescaped" rule into a form which, while not
being a mechanical translation of the original rule, matches the same
characters in the whole Unicode range. It also macthes textual
description of string representation in RFC 7159:

  All Unicode characters may be placed within the quotation marks,
  except for the characters that must be escaped: quotation mark,
  reverse solidus, and the control characters (U+0000 through U+001F).

Fixes #417.
8 years ago
David Majda 6a04067a76 bin/pegjs: Do not overwrite extension-less files
Running bin/pegjs with one argument which was an extension-less file
name caused the file to be overwritten. This was because internal
extension rewriting logic didn't handle this case corectly.

This commit changes the logic from regexp-based to path.extname-based,
fixing the problem. The new code generates file names like this:

  Input file name     Output file name
  ------------------------------------
  grammar.ext         grammar.js
  grammar.ext1.ext2   grammar.ext1.js
  grammar.            grammar.js
  grammar             grammar.js

Fixes #405.
8 years ago
David Majda 5eb6225ef0 Merge pull request #420 from bkutil/patch-1
Grammar fix in ISSUE_TEMPLATE.md and CONTRIBUTING.md
8 years ago
Balázs Kutil 7f2358af1f Grammar fix in ISSUE_TEMPLATE.md and CONTRIBUTING.md 8 years ago
David Majda 4d85464ac4 README.md: Fix npm & Bower badges to show PEG.js version
Based on a pull request by Daniel Baird (@DanielBaird):

  https://github.com/pegjs/pegjs/pull/419
8 years ago