Commits on Sep 4, 2013

1. repl: Catch syntax errors better …

   Replace the growing list of 'isSyntaxError' whackamole conditions with a
   smarter approach.  This creates a vm Script object *first*, which will
   parse the code and raise a SyntaxError right away.
   
   We still do need the test function, but only because strict mode syntax
   errors are not recoverable, and should be raised right away.  Really, we
   should probably *only* continue on "unexpected end of input" SyntaxErrors.
   
   Also fixes a very difficult-to-test nit where the '...' indentation is
   not properly cleared when you ^C out of a syntax error.
   
   Closes #6093

   

   isaacs committed Sep 4, 2013
   Copy the full SHA

   4631c50 View commit details

   Browse the repository at this point in the history

2. repl: treat "Assignment to const" as syntax error …

   Adding a new `repl-harmony` test file here because adding the
   `--use_strict --harmony` flags on the main repl test file was causing
   lots of unrelated failures, due to global variable assignments and
   things like that. This new test file is based off of the original
   repl.js test file, but has a lot of the tests stripped out. A test case
   for this commit is included though.
   
   Fixes #6132.

   

   TooTallNate authored and isaacs committed Sep 4, 2013
   Copy the full SHA

   54fbb1d View commit details

   Browse the repository at this point in the history

3. repl: Simplify paren wrap, continuation-detection …

   This simplifies the logic that was in isSyntaxError, as well as the
   choice to wrap command input in parens to coerce to an expression
   statement.
   
   1. Rather than a growing blacklist of allowed-to-throw syntax errors,
   just sniff for the one we really care about ("Unexpected end of input")
   and let all the others pass through.
   
   2. Wrapping {a:1} in parens makes sense, because blocks and line labels
   are silly and confusing and should not be in JavaScript at all.
   However, wrapping functions and other types of programs in parens is
   weird and required yet *more* hacking to work around.  By only wrapping
   statements that start with { and end with }, we can handle the confusing
   use-case, without having to then do extra work for functions and other
   cases.
   
   This also fixes the repl wart where `console.log)(` works in the repl,
   but only by virtue of the fact that it's wrapped in parens first, as
   well as potential side effects of double-running the commands, such as:
   
       > x = 1
       1
       > eval('x++; throw new SyntaxError("e")')
       ... ^C
       > x
       3

   

   isaacs committed Sep 4, 2013
   Copy the full SHA

   9ef9a9d View commit details

   Browse the repository at this point in the history