The current working directory may not exist when the REPL starts up.
Don't treat that as an error because it's still possible to do many
useful things. This is like the previous commit but for the REPL.
Fixes: https://github.com/iojs/io.js/issues/1184
PR-URL: https://github.com/iojs/io.js/pull/1194
Reviewed-By: Johan Bergström <bugs@bergstroem.nu>
Reviewed-By: Rod Vagg <rod@vagg.org>
Many of the util.is*() methods used to check data types
simply compare against a single value or the result of
typeof. This commit replaces calls to these methods with
equivalent checks. This commit does not touch calls to the
more complex methods (isRegExp(), isDate(), etc.).
Fixes: https://github.com/iojs/io.js/issues/607
PR-URL: https://github.com/iojs/io.js/pull/647
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This commit replaces a number of var statements throughout
the lib code with const statements.
PR-URL: https://github.com/iojs/io.js/pull/541
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Let REPL enter multiline mode if user's input contains unterminated
template literals.
PR-URL: https://github.com/iojs/io.js/pull/333
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The copyright and license notice is already in the LICENSE file. There
is no justifiable reason to also require that it be included in every
file, since the individual files are not individually distributed except
as part of the entire package.
I introduced this module over a year ago in a pull request as the v8
module but it was quickly subsumed by the tracing module.
The tracing module was recently removed again and that is why this
commit introduces the v8 module again, including the new features it
picked up commits d23ac0e and f8076c4.
PR-URL: https://github.com/iojs/io.js/pull/131
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Reviewed-By: Christian Tellnes <christian@tellnes.no>
Reviewed-By: Thorsten Lorenz <thlorenz@gmx.de>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Async Listener was the name of the user-facing JS API, and is being
completely removed. Instead low level hooks directly into the mechanism
that AL used will be introduced in a future commit.
PR-URL: https://github.com/joyent/node/pull/8110
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Reviewed-by: Fedor Indutny <fedor@indutny.com>
Reviewed-by: Alexis Campailla <alexis@janeasystems.com>
Reviewed-by: Julien Gilli <julien.gilli@joyent.com>
Turn on strict mode for the files in the lib/ directory. It helps
catch bugs and can have a positive effect on performance.
PR-URL: https://github.com/node-forward/node/pull/64
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
The refactor in 3ae0b17c broke the multiline input's visual appearence.
While actually switching to this mode, the `...` prefix is not
displayed.
Additionally, account only SyntaxErrors that are happening at the parse
time, everything else should not be switching repl to the multiline
mode.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Add a new 'tracing' module with a v8 property that lets the user
register listeners for gc events. The listeners are invoked after
every garbage collection cycle with 'before' and 'after' statistics.
Useful for monitoring tools that want to keep track of memory usage.
Fix invalid `hasOwnProperty` function usage.
For example, before in the REPL:
```
> Ar<Tab>
Array
Array ArrayBuffer
```
Now:
```
> Ar<Tab>
Array
ArrayBuffer
```
Fixes#6255.
Closes#6498.
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
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.
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
Passing a filename is still supported in place of certain options
arguments, for backward-compatibility, but timeout and display-errors
are not translated since those were undocumented.
Also managed to eliminate an extra stack trace line by not calling
through the `createScript` export.
Added a few message tests to show how `displayErrors` works.
This is an important part of the repl use-case.
TODO: The arg parsing in vm.runIn*Context() is rather wonky.
It would be good to move more of that into the Script class,
and/or an options object.
Before this, entering something like:
> JSON.parse('066');
resulted in the "..." prompt instead of displaying the expected
"SyntaxError: Unexpected number"
The try/catch in repl.js keeps any active domain from catching the
error. Since the domain may not even be enterd until the code is run,
it's not possible to avoid the try/catch, so emit on the domain when an
error is thrown.
In JS, the expression ".1" is a floating point number. Issue 4268 concerns the
REPL interpreting floating point numbers that lead with a "." as keywords. The
original bugfix worked for this specific case but not for the general case:
var x = [
.1,
.2,
.3
];
The attached change and test (`.1+.1` should be `.2`) fix the bug.
Closes#4513.
Don't give names of built-in libraries special treatment.
Changes the REPL's behavior from this:
> var path = 42
> path
A different "path" already exists globally
To this:
> var path = 42
> path
42
Fixes#4512.
Fixes#3226.
Consider a production server that uses a REPL to debug. Creating the instance
would wipe out the global cache of modules, and subsequent "require" calls in
the server would be reloaded from disk. The REPL should observe only, without
altering, its environment.
Before there was this weird module-scoped "context" variable which seemingly
shared the "context" of subsequent REPL instances, unless ".clear" was invoked
inside the REPL. To be proper, we need to ensure that each REPL gets its own
"context" object. I literally don't know why this "sharing" behavior was in place
before, but it was just plain wrong.
Ben Noordhuis
cjihrig
Xiaowei Li
Yosuke Furukawa
isaacs
Bert Belder
Trevor Norris
Fedor Indutny
Yazhong Liu
Brian White
Timothy J Fontaine
Yazhong Liu
Maciej Małecki
Nathan Rajlich
Domenic Denicola
Sami Samhuri
Dave Olszewski
Ryunosuke SATO
Felix Böhm
Nirk Niggler