This fixes how Object.defineProperty() defines JavaScript accessors on
objects with installed API interceptors. The definition itself does not
cause any interceptors to be called, whereas any subsequent accesses on
said object will still fire the interceptor. This behavior is in sync
with API accessors.
R=rossberg@chromium.org
BUG=v8:1651,chromium:94666
TEST=cctest/test-api
Review URL: http://codereview.chromium.org/9021019
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10293 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
The first attempt did not properly handle keyed loads/stores and
did not check the constructors of the objects in the prototype
chain.
Added two more tests to handle the fixed cases.
BUG=v8:1823
TEST=LeakGlobalObjectViaMapKeyed,LeakGlobalContextViaMapProto
Review URL: http://codereview.chromium.org/8974009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10277 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 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
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
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
So far the parser had its own harmony flag to disable the harmony scoping
feature when parsing native functions. With the introduction of the extended
language mode this becomes unnecessary because native functions will never enter
the extended mode. The parser can thus track FLAG_harmony_scoping and the
language mode of the current scope to see if harmony features are allowed. The
scanner and preparser have to keep their flag, because they can't use
FLAG_harmony_scoping as it is not available for the preparser-process
executable.
This depends on:
http://codereview.chromium.org/8417035/
Review URL: http://codereview.chromium.org/8562002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10063 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
This CL introduces a third mode next to the non-strict
(henceforth called 'classic mode') and 'strict mode'
which is called 'extended mode' as in the current
ES.next specification drafts. The extended mode is based on
the 'strict mode' and adds new functionality to it. This
means that most of the semantics of these two modes
coincide.
The 'extended mode' is entered instead of the 'strict mode'
during parsing when using the 'strict mode' directive
"use strict" and when the the harmony-scoping flag is
active. This should be changed once it is fully specified how the 'extended mode' is entered.
This change introduces a new 3 valued enum LanguageMode
(see globals.h) corresponding to the modes which is mostly
used by the frontend code. This includes the following
components:
* (Pre)Parser
* Compiler
* SharedFunctionInfo, Scope and ScopeInfo
* runtime functions: StoreContextSlot,
ResolvePossiblyDirectEval, InitializeVarGlobal,
DeclareGlobals
The old enum StrictModeFlag is still used in the backend
when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
* SetProperty runtime function, Delete builtin
* StoreIC and KeyedStoreIC
* StubCache
Review URL: http://codereview.chromium.org/8417035
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
So far free variables references in eval code are not statically
resolved. For example in
function foo() { var x = 1; eval("y = x"); }
the variable x will get mode DYNAMIC and y will get mode DYNAMIC_GLOBAL,
i.e. free variable references trigger dynamic lookups with a fast case
handling for global variables.
The CL introduces static resolution of free variables references in eval
code. If possible variable references are resolved to bindings belonging to
outer scopes of the eval call site.
This is achieved by deserializing the outer scope chain using
Scope::DeserializeScopeChain prior to parsing the eval code similar to lazy
parsing of functions. The existing code for variable resolution is used,
however resolution starts at the first outer unresolved scope instead of
always starting at the root of the scope tree.
This is a prerequisite for statically checking validity of assignments in
the extended code as specified by the current ES.next draft which will be
introduced by a subsequent CL. More specifically section 11.13 of revision 4
of the ES.next draft 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.
TEST=existing tests in mjsunit
Review URL: http://codereview.chromium.org/8508052
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9999 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
