For calls of the form ident(...) record position of the identifier as the position of the call. For other calls record positions of the opening parenthesis.
This guarantees that for expressions of the form function(){}() call position will not intersect with positions recorded for function literal which is used by the debugger for scope chain resolution.
R=kmillikin@chromium.org
BUG=http://crbug.com/109195
TEST=test/mjsunit/regress/regress-109195.js
Review URL: http://codereview.chromium.org/9125001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10350 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
CPU-eating DOS attacks against node.js servers. Based on code from
Bert Belder. This version only solves the issue for those that compile
V8 themselves or those that do not use snapshots. A snapshot-based
precompiled V8 will still have predictable string hash codes.
Review URL: http://codereview.chromium.org/9086006
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10330 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We use foreign callbacks to make some properties shadow internal values
but still behave as data properties from within JavaScript. This means
when a value is passed to Object.defineProperty() on such a property,
it should update the internal value instead of redefinind the property
and destroying the shadowing.
R=rossberg@chromium.org
BUG=v8:1530
TEST=mjsunit/regress/regress-1530,test262/S15.3.3.1_A4
Review URL: http://codereview.chromium.org/8996008
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10279 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This test deleted its working directory and then tried to run several
shell commands which caused a failure on nfs.
Changes:
-TEST_DIR is only removed at the very end of the test
-the working directory is changed to /tmp at the beginning so that
every iteration (when running with --stress-opt) has a valid working directory
BUG=
TEST=
Review URL: http://codereview.chromium.org/8936004
Patch from Daniel Kalmar <kalmard@homejinni.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10240 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL adds support for loading from and storing to context slots
belonging to harmony let or const bound variables. Checks for the
hole value are performed and the function is deoptimized if they fail.
The full-codegen generated code will take care of properly throwing
a reference error in these cases.
TEST=mjsunit/harmony/block-let-crankshaft.js
Review URL: http://codereview.chromium.org/8820015
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10220 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This is the first CL in a series that add support for the harmony scoping
features to crankshaft. This CL specifically adds support for stack
allocated 'let' and 'const' declared variables in function scopes.
TEST=mjsunit/harmony/block-let-crankshaft.js
Review URL: http://codereview.chromium.org/8806012
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10171 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The ES.next draft rev 4 in section 11.13 reads:
It is a Syntax Error if the AssignmentExpression is contained in extended code
and the LeftHandSideExpression is an Identifier that does not statically resolve
to a declarative environment record binding or if the resolved binding is an
immutable binding.
This CL adds corresponding static checks for the immutable binding case.
TEST=mjsunit/harmony/block-const-assign
Review URL: http://codereview.chromium.org/8688007
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10156 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The debugger preparation did not take optimized functions - including
inlined function into account. This caused the full-code used for
deoptimization to be the "lazy compile" builtin which did not work and
caused V8 to crash.
R=yangguo@chromium.org
BUG=chromium:105375, v8:1782
TEST=test/mjsunit/debug-break-inline.js
Review URL: http://codereview.chromium.org//8728031
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10094 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The ES.next drafts require that source code that matches the productions for
let and const bindings outside the extended mode trigger early syntax
errors. This CL adapts the parser / preparser accordingly under the harmony
scoping flag.
Summary:
* Harmony scoping flag not set: Old semantics allowing const in classic mode
with function level scope. Const binding in strict mode and let bindings in
classic and strict mode trigger early syntax errors.
* Harmony scoping is set: Use new harmony const and let in
extended mode and old const in classic mode. This is to preserve
compatibility with current web pages that already use
non-standard implementations of const. An early syntax error is
thrown on const in strict mode and on let in classic and strict
mode.
This depends on:
http://codereview.chromium.org/8562002/
TEST=mjsunit/harmony/block-early-errors.js
Review URL: http://codereview.chromium.org/8564001
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10079 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
source code positions it gets from the program counter to recreate the scope
chain by reparsing the function or program.
This CL includes the following changes
* Adds source code positions for the assignment added by the rewriter.
* Run the preparser over global code first.
* Use the ScopeType from the ScopeInfo to determine if the code being debugged
is eval, function or global code instead of looking up the '.result' symbol.
TEST=mjsunit/debug-stepout-scope.js
Review URL: http://codereview.chromium.org/8590027
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10076 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
