- 05 Dec, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 29 Nov, 2011 1 commit
-
-
keuchel@chromium.org authored
This reapplies a fixed version of r10076 that also works on arm. Patch set one is r10076 reapplied and patch set 2 contains the new fix. Review URL: http://codereview.chromium.org/8725001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10080 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 28 Nov, 2011 2 commits
-
-
keuchel@chromium.org authored
Review URL: http://codereview.chromium.org/8716005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10077 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
keuchel@chromium.org authored
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
-
- 24 Nov, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 18 Nov, 2011 3 commits
-
-
yangguo@chromium.org authored
BUG= TEST= Review URL: http://codereview.chromium.org/8595007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10029 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
Review URL: http://codereview.chromium.org/8561011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10028 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
yangguo@chromium.org authored
Note that some cctests and d8 still contain statical members with exit time destructors. BUG=v8:1828 Review URL: http://codereview.chromium.org/8586025 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10025 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 15 Nov, 2011 1 commit
-
-
keuchel@chromium.org authored
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
-
- 03 Nov, 2011 4 commits
-
-
keuchel@chromium.org authored
Review URL: http://codereview.chromium.org/8438071 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9874 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
keuchel@chromium.org authored
After introduction of with scopes we have enough static information to omit context allocation in the case that a variable is accessed from a nested block or catch scope of the same function. Only variables accessed from the inside of a nested function or with scope are forced to be allocated in the context. This essentially reverts http://code.google.com/p/v8/source/detail?r=9281 . which in turn reverted an earlier change. Review URL: http://codereview.chromium.org/8431001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9872 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
keuchel@chromium.org authored
This depends on http://codereview.chromium.org/8352039/ . Review URL: http://codereview.chromium.org/8423005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9869 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
keuchel@chromium.org authored
Both classes have been merged into a single ScopeInfo class that implements the functionality from both. This CL does not adapt the broken gdb-jit interface. Review URL: http://codereview.chromium.org/8352039 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9868 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Nov, 2011 1 commit
-
-
fschneider@chromium.org authored
This avoid duplicating the code for each template instance. Also remove dead code from different places in our code base. Removed some verification code from release builds. Review URL: http://codereview.chromium.org/8387070 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9860 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 25 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
This implements block scoped 'const' declared variables in harmony mode. They have a temporal dead zone semantics similar to 'let' bindings, i.e. accessing uninitialized 'const' bindings in throws a ReferenceError. As for 'let' bindings, the semantics of 'const' bindings in global scope is not correctly implemented yet. Furthermore assignments to 'const's are silently ignored. Another CL will introduce treatment of those assignments as early errors. Review URL: http://codereview.chromium.org/7992005 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9764 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
Review URL: http://codereview.chromium.org/8344082 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9746 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
This also includes the two fixes from r9674 and r9675. Here's the diff to the previous CL. --- a/src/runtime.cc +++ b/src/runtime.cc @@ -11133,17 +11133,26 @@ class ScopeIterator { context_(Context::cast(frame->context())), nested_scope_chain_(4) { + // Catch the case when the debugger stops in an internal function. + Handle<SharedFunctionInfo> shared_info(function_->shared()); + if (shared_info->script() == isolate->heap()->undefined_value()) { + if (shared_info->scope_info()->HasContext()) Next(); + return; + } + // Check whether we are in global code or function code. If there is a stack // slot for .result then this function has been created for evaluating // global code and it is not a real function. // Checking for the existence of .result seems fragile, but the scope info // saved with the code object does not otherwise have that information. - int index = function_->shared()->scope_info()-> + int index = shared_info->scope_info()-> StackSlotIndex(isolate_->heap()->result_symbol()); // Reparse the code and analyze the scopes. ZoneScope zone_scope(isolate, DELETE_ON_EXIT); - Handle<SharedFunctionInfo> shared_info(function_->shared()); Handle<Script> script(Script::cast(shared_info->script())); Scope* scope; if (index >= 0) { Review URL: http://codereview.chromium.org/8344046 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9734 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
This reverts commits r9673: "Scope tree serialization and ScopeIterator cleanup." r9674: "Use OS::SNPrintF instead of snprintf." r9675: "Use int instead of size_t, StrLength instead of strlen." Review URL: http://codereview.chromium.org/8353003 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9703 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
The intention is to store enough scope information for the debugger to handle stack allocation of block scoped variables introduced by http://codereview.chromium.org/7860045/ . This CL is based on http://codereview.chromium.org/7904008/ . Review URL: http://codereview.chromium.org/7979001 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9673 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Oct, 2011 1 commit
-
-
keuchel@chromium.org authored
Review URL: http://codereview.chromium.org/7904008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9650 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Oct, 2011 1 commit
-
-
fschneider@chromium.org authored
This eliminates compile-errors when assigning Handle<SerializedScopeInfo> to Handle<Object> in a place where the declaration was not available because variables.h was not included. As a result I had to also move the enum Variable::Mode to v8globals.h and rename it to VariableMode. Review URL: http://codereview.chromium.org/8221004 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9575 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 14 Sep, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG=96523 TEST=mjsunit/regress/regress-96523.js Review URL: http://codereview.chromium.org/7890031 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9281 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Sep, 2011 1 commit
-
-
mikhail.naganov@gmail.com authored
As pointed out in: http://codereview.chromium.org/7754007/#msg5 "SmartPointer should have been named SmartArrayPointer as it expects an input allocated using new[] and deallocates it using delete[]. Using it as a simple scoped pointer for a single object is incorrect." R=mnaganov@chromium.org Review URL: http://codereview.chromium.org/7860011 Patch from Thiago Farina <tfarina@chromium.org>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9215 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 07 Sep, 2011 1 commit
-
-
kmillikin@chromium.org authored
R=fschneider@chromium.org BUG= TEST= Review URL: http://codereview.chromium.org/7824038 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9162 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 02 Sep, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG= TEST= Review URL: http://codereview.chromium.org/7825006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9117 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Sep, 2011 2 commits
-
-
fschneider@chromium.org authored
The changes to scopes and parser introduce a VariableProxy wrapping the function-name variable for function literals. It seems the easiest way to get an AST id for the HSimulate after context-slot stores in declarations. Review URL: http://codereview.chromium.org/7826009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9112 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
keuchel@chromium.org authored
BUG= TEST=mjsunit/harmony/block-conflicts.js Review URL: http://codereview.chromium.org/7756014 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9102 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Aug, 2011 1 commit
-
-
keuchel@chromium.org authored
Implementation of the harmony block scoped let bindings as proposed here: http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings Changes to the syntax are explained there. They are active under the harmony_block_scoping_ flag in the parser. Review URL: http://codereview.chromium.org/7616009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8944 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Aug, 2011 1 commit
-
-
keuchel@chromium.org authored
BUG= TEST= Review URL: http://codereview.chromium.org/7549008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8911 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Jul, 2011 1 commit
-
-
vitalyr@chromium.org authored
R=ager@chromium.org Review URL: http://codereview.chromium.org/7399023 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8678 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 15 Jul, 2011 1 commit
-
-
vitalyr@chromium.org authored
R=ager@chromium.org Review URL: http://codereview.chromium.org/7383013 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8664 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Jul, 2011 1 commit
-
-
svenpanne@chromium.org authored
ZoneAllocationPolicy::New is not inlined anymore because this pulls in far too much stuff and doesn't really make any measurable performance difference. And no, the #includes are still not in alphabetical order... ;-) Review URL: http://codereview.chromium.org/7346006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8616 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Jul, 2011 1 commit
-
-
kmillikin@chromium.org authored
We were only looking one level up the scope chain to decide which closure to use in the fresh context. Instead, we should look to the first non-catch scope. R=vegorov@chromium.org BUG=1528 TEST=regress-1528 Review URL: http://codereview.chromium.org/7309002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8523 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 01 Jul, 2011 1 commit
-
-
kmillikin@chromium.org authored
When optimizing a function defined inside a catch, we did not count the catch context as part of the context chain. R=vegorov@chromium.org BUG=1521 TEST=regress-1521 Review URL: http://codereview.chromium.org/7285032 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8518 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jun, 2011 1 commit
-
-
kmillikin@chromium.org authored
The catch variable is bound in the catch scope. For simplicity in this initial implementation, it is always allocated even if unused and always allocated to a catch context even if it doesn't escape. The presence of catch is no longer treated as a with. In this change, care must be taken to distinguish between the scope where a var declaration is hoisted to and the scope where the initialization occurs. R=ager@chromium.org BUG= TEST= Review URL: http://codereview.chromium.org/7280012 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8496 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Jun, 2011 2 commits
-
-
karlklose@chromium.org authored
Review URL: http://codereview.chromium.org/7187007 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8315 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
karlklose@chromium.org authored
This reverts commit ceb31498b9d69edca3260820fb4047045891ce6d. TBR=kmillikin@chromium.org Review URL: http://codereview.chromium.org/7172030 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8308 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 15 Jun, 2011 1 commit
-
-
karlklose@chromium.org authored
Review URL: http://codereview.chromium.org/7167006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8300 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 May, 2011 1 commit
-
-
kmillikin@chromium.org authored
Eliminate the LocalType enum in favor of a pair of functions, one for var and const declarations and one for parameters. Move the responsibility for adding a parameter variable to the Scope's internal data structure into the Scope and out of the parser. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8091 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 May, 2011 1 commit
-
-
sgjesse@chromium.org authored
Review URL: http://codereview.chromium.org//7003030 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@7892 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-