This introduces an additional check into the StoreIC_ArrayLength builtin
checking that the array still has fast properties. Redifinitions of the
length property that would cause it's type or attributes to change, will
switch to slow properties, thereby invalidating said optimization.
R=svenpanne@chromium.org
BUG=v8:1756
TEST=test262
Review URL: http://codereview.chromium.org/8895025
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10254 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
("narrowing conversion ... inside { } is ill-formed in C++11").
* src/mksnapshot.cc: Cast "char" to "unsigned char" when outputting snapshot.
* test/cctest/test-regexp.cc: Use static_cast to uc16 as the char
literal is signed.
Review URL: http://codereview.chromium.org/8825003
Patch from Tobias Burnus <burnus@net-b.de>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10241 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 CL fixes the preparser to have the same liberal automatic semicolon
insertion behaviour as the parser. In the case of a return statement in
global code we throw a syntax error at runtime rather than an early error
due to compatibility with KJS. However that hack allowed the following
syntactically incorrect program in global code in the parser but not in
the preparser:
if (false) return else {}
while the slightly saner version with the obligatory semicolon
if (false) return; else {}
was disallowed in the parser, but the preparser allowed it. This CL also
fixes that issue.
BUG=v8:1856
TEST=cctest/test-parsing.cc
Review URL: http://codereview.chromium.org/8844002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10201 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
a mark-sweep. We have a soft limit on old space size, which is designed to
trigger an old-space collection when we hit it. Unfortunately although the
soft limit had already triggered an old space collection, the soft limit was
preventing objects from new space from being promoted. For every promotion
candidate we were checking 3 different ways to allocate in old space before
giving up and putting the object in the other semispace. This change allows
the promoted objects to go to old space and also makes us more eager to
sweep a page before trying other ways to find space for an object.
Review URL: http://codereview.chromium.org/8748005
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10092 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
