- 19 Sep, 2014 1 commit
-
-
titzer@chromium.org authored
R=danno@chromium.org, mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/582703002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24083 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 04 Aug, 2014 1 commit
-
-
bmeurer@chromium.org authored
This way we don't clash with the ASSERT* macros defined by GoogleTest, and we are one step closer to being able to replace our homegrown base/ with base/ from Chrome. R=jochen@chromium.org, svenpanne@chromium.org Review URL: https://codereview.chromium.org/430503007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22812 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jul, 2014 1 commit
-
-
danno@chromium.org authored
R=mstarzinger@chromium.org Review URL: https://codereview.chromium.org/426233002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22709 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 30 Jun, 2014 1 commit
-
-
rossberg@chromium.org authored
R=marja@chromium.org BUG= Review URL: https://codereview.chromium.org/349033006 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22096 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 26 Jun, 2014 1 commit
-
-
rossberg@chromium.org authored
R=titzer@chromium.org BUG= Review URL: https://codereview.chromium.org/345573002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22039 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 24 Jun, 2014 1 commit
-
-
marja@chromium.org authored
This is a reincarnation of r21841. The previous try was https://codereview.chromium.org/314603004/ but it regressed JSBench and morejs. BUG= R=rossberg@chromium.org Review URL: https://codereview.chromium.org/335293004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21972 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Jun, 2014 1 commit
-
-
marja@chromium.org authored
Plus the fixes on top. Reason: regresses benchmarks (JSBench) and perf (morejs). TBR=rossberg@chromium.org BUG=385404 LOG=N Review URL: https://codereview.chromium.org/345513003 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21882 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Jun, 2014 1 commit
-
-
marja@chromium.org authored
This is needed so that we can run Parser on a non-main thread (independent of the Isolate and the V8 heap). BUG= R=rossberg@chromium.org Review URL: https://codereview.chromium.org/314603004 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21841 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jun, 2014 1 commit
-
-
jochen@chromium.org authored
- this avoids using relative include paths which are forbidden by the style guide - makes the code more readable since it's clear which header is meant - allows for starting to use checkdeps BUG=none R=jkummerow@chromium.org, danno@chromium.org LOG=n Review URL: https://codereview.chromium.org/304153016 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21625 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 May, 2014 1 commit
-
-
rossberg@chromium.org authored
R=yangguo@chromium.org BUG= Review URL: https://codereview.chromium.org/291153005 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@21441 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Apr, 2014 1 commit
-
-
bmeurer@chromium.org authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/259183002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@21035 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Mar, 2014 2 commits
-
-
rossberg@chromium.org authored
- Merge LanguageMode and StrictModeFlag enums - Make harmony-scoping depend only on strict mode - Free some bits on the way - Plus additional clean-up and renaming R=ulan@chromium.org BUG= Review URL: https://codereview.chromium.org/181543002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19800 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
R=mstarzinger@chromium.org BUG= Review URL: https://codereview.chromium.org/177683002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19799 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 06 Jun, 2013 1 commit
-
-
rossberg@chromium.org authored
More importantly, do a bunch of renamings of incidental existing "types" to avoid actual and potential name clashes (and also to improve consistency). R=svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/16549002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14978 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Apr, 2013 1 commit
-
-
mstarzinger@chromium.org authored
* src/scopes.h (ForceContextAllocation, has_forced_context_allocation): New interface to force context allocation for an entire function's scope. * src/scopes.cc: Unless a new scope is a function scope, if its outer scope has forced context allocation, it should also force context allocation. (MustAllocateInContext): Return true if the scope as a whole has forced context allocation. (CollectStackAndContextLocals): Allow temporaries to be context-allocated. * src/parser.cc (ParseFunctionLiteral): Force context allocation for generator scopes. * src/v8globals.h (VariableMode): Update comment on TEMPORARY. * src/arm/full-codegen-arm.cc (Generate): * src/ia32/full-codegen-ia32.cc (Generate): * src/x64/full-codegen-x64.cc (Generate): Assert that generators have no stack slots. * test/mjsunit/harmony/generators-instantiation.js: New test. BUG=v8:2355 TEST=mjsunit/harmony/generators-instantiation Review URL: https://codereview.chromium.org/13408005 Patch from Andy Wingo <wingo@igalia.com>. git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14152 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 Dec, 2012 1 commit
-
-
rossberg@chromium.org authored
Also, add test that assignment to function name is a syntax error with harmony scoping. Does not fix issue 2243 directly, but with ES6, the required behaviour will change to what is implemented already anyway. R=yangguo@chromium.org BUG=v8:2243 Review URL: https://codereview.chromium.org/11607016 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13234 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 22 Nov, 2012 1 commit
-
-
rossberg@chromium.org authored
Modules now have their own local scope, represented by their own context. Module instance objects have an accessor for every export that forwards access to the respective slot from the module's context. (Exports that are modules themselves, however, are simple data properties.) All modules have a _hosting_ scope/context, which (currently) is the (innermost) enclosing global scope. To deal with recursion, nested modules are hosted by the same scope as global ones. For every (global or nested) module literal, the hosting context has an internal slot that points directly to the respective module context. This enables quick access to (statically resolved) module members by 2-dimensional access through the hosting context. For example, module A { let x; module B { let y; } } module C { let z; } allocates contexts as follows: [header| .A | .B | .C | A | C ] (global) | | | | | +-- [header| z ] (module) | | | +------- [header| y ] (module) | +------------ [header| x | B ] (module) Here, .A, .B, .C are the internal slots pointing to the hosted module contexts, whereas A, B, C hold the actual instance objects (note that every module context also points to the respective instance object through its extension slot in the header). To deal with arbitrary recursion and aliases between modules, they are created and initialized in several stages. Each stage applies to all modules in the hosting global scope, including nested ones. 1. Allocate: for each module _literal_, allocate the module contexts and respective instance object and wire them up. This happens in the PushModuleContext runtime function, as generated by AllocateModules (invoked by VisitDeclarations in the hosting scope). 2. Bind: for each module _declaration_ (i.e. literals as well as aliases), assign the respective instance object to respective local variables. This happens in VisitModuleDeclaration, and uses the instance objects created in the previous stage. For each module _literal_, this phase also constructs a module descriptor for the next stage. This happens in VisitModuleLiteral. 3. Populate: invoke the DeclareModules runtime function to populate each _instance_ object with accessors for it exports. This is generated by DeclareModules (invoked by VisitDeclarations in the hosting scope again), and uses the descriptors generated in the previous stage. 4. Initialize: execute the module bodies (and other code) in sequence. This happens by the separate statements generated for module bodies. To reenter the module scopes properly, the parser inserted ModuleStatements. R=mstarzinger@chromium.org,svenpanne@chromium.org BUG= Review URL: https://codereview.chromium.org/11093074 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@13033 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 05 Oct, 2012 1 commit
-
-
rossberg@chromium.org authored
R=mstarzinger@chromium.org BUG=v8:2322 Review URL: https://codereview.chromium.org/11035054 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12668 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 27 Aug, 2012 1 commit
-
-
rossberg@chromium.org authored
They are yet unused; actual allocation of global lexical bindings in these contexts is implemented in a separate follow-up CL. R=svenpanne@chromium.org BUG= Review URL: https://chromiumcodereview.appspot.com/10876067 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12384 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 17 Aug, 2012 1 commit
-
-
rossberg@chromium.org authored
in anticipation of the upcoming lexical global scope. Mostly automatised as: for FILE in `egrep -ril "global[ _]?context" src test/cctest` do echo $FILE sed "s/Global context/Native context/g" <$FILE >$FILE.0 sed "s/global context/native context/g" <$FILE.0 >$FILE.1 sed "s/global_context/native_context/g" <$FILE.1 >$FILE.2 sed "s/GLOBAL_CONTEXT/NATIVE_CONTEXT/g" <$FILE.2 >$FILE.3 sed "s/GlobalContext/NativeContext/g" <$FILE.3 >$FILE rm $FILE.[0-9] done R=mstarzinger@chromium.org BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/10832342 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12325 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Jul, 2012 1 commit
-
-
rossberg@chromium.org authored
(in preparation for handling imports). R=svenpanne@chromium.org BUG=v8:1569 TEST= Review URL: https://chromiumcodereview.appspot.com/10698167 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12078 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 09 Jul, 2012 1 commit
-
-
rossberg@chromium.org authored
Specifically: - In parser, check that all exports are defined. - Move JSModule allocation from parser to scope resolution. - Move JSModule linking from full codegen to scope resolution. - Implement module accessors for exported value members. - Allocate module contexts statically along with JSModules (to allow static linking), but chain them when module literal is evaluated. - Make module contexts' extension slot refer to resp. JSModule (makes modules' ScopeInfo accessible from context). - Some other tweaks to context handling in general. - Make any code containing module literals (and thus embedding static references to JSModules) non-cacheable. This enables accessing module instance objects as expected. Import declarations are a separate feature and do not work yet. R=mstarzinger@chromium.org BUG=v8:1569 TEST= Review URL: https://chromiumcodereview.appspot.com/10690043 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12010 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 03 Jul, 2012 1 commit
-
-
mstarzinger@chromium.org authored
This prevents lazy compilation of functions that have an outer context containing a strict eval scope. Such a scope potentially contains context allocated variables in an artificial function scope that is not deserialized correctly. R=ulan@chromium.org BUG=chromium:135066 TEST=mjsunit/regress/regress-crbug-135066 Review URL: https://chromiumcodereview.appspot.com/10704058 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11976 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 19 Jun, 2012 1 commit
-
-
mstarzinger@chromium.org authored
This changes the compiler to be more aggressive about lazy compilation of closures with non-trivial outer context. Compilation can only be triggered with a valid outer context now. One exception is the debugger, which can request compilation of arbitrary shared code, but it ensures to trigger compilation only at points where no context is needed. This relands r11782, r11783, r11790 and a minor fix. R=ulan@chromium.org TEST=mjsunit/debug-script-breakpoints-nested Review URL: https://chromiumcodereview.appspot.com/10543141 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11866 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 13 Jun, 2012 1 commit
-
-
mstarzinger@chromium.org authored
R=danno@chromium.org Review URL: https://chromiumcodereview.appspot.com/10536142 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11796 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 12 Jun, 2012 1 commit
-
-
mstarzinger@chromium.org authored
This changes the compiler to be more aggressive about lazy compilation of closures with non-trivial outer context. Compilation can only be triggered with a valid outer context now. One exception is the debugger, which can request compilation of arbitrary shared code, but it ensures to trigger compilation only at points where no context is needed. R=ulan@chromium.org TEST=mjsunit/debug-script-breakpoints-nested Review URL: https://chromiumcodereview.appspot.com/10538102 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11782 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 11 Jun, 2012 1 commit
-
-
sanjoy@chromium.org authored
By passing around a Zone object explicitly we no longer need to do a TLS access at the sites that allocate memory from the current Zone. BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/10534006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11761 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 18 May, 2012 1 commit
-
-
ulan@chromium.org authored
Disable optimization for functions that have scopes that cannot be reconstructed from the context chain. BUG=v8:2071 TEST=mjsunit/regress/regress-2071.js Review URL: https://chromiumcodereview.appspot.com/10388164 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11592 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 16 Apr, 2012 1 commit
-
-
rossberg@chromium.org authored
Do proper dispatch on declaration type instead of mingling together different code generation paths. Once we add more declaration forms, this is more scalable. In separate steps, I'd like to (1) clean up the logic for DeclareGlobal, and (2) try to reduce the special handling of the name function var if possible. R=fschneider@chromium.org BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/9704054 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11331 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Mar, 2012 1 commit
-
-
rossberg@chromium.org authored
All module expressions, and all variables that might refer to modules, are assigned interfaces (module types) that are resolved using unification. This is necessary to deal with the highly recursive nature of ES6 modules, which does not allow any kind of bottom-up strategy for resolving module names and paths. Error messages are rudimental right now. Probably need to track more information to make them nicer. R=svenpanne@chromium.org BUG=v8:1569 TEST= Review URL: https://chromiumcodereview.appspot.com/9615009 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10966 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 29 Feb, 2012 1 commit
-
-
jkummerow@chromium.org authored
Review URL: https://chromiumcodereview.appspot.com/9535006 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10873 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 23 Feb, 2012 1 commit
-
-
fschneider@chromium.org authored
The old HashMap class had an explicit member to determine the allocation policy. The template version matches the approach used already for lists. Cleanup some include dependencies and unnecessary forward declarations. Cleanup some dead code from isolate.h and replace some HEAP macros with GetHeap(). Review URL: https://chromiumcodereview.appspot.com/9372106 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10806 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 20 Feb, 2012 1 commit
-
-
rossberg@chromium.org authored
Module definitions are not compiled or otherwise executed yet. Toplevel module identifiers are bound but never initialized. R=kmillikin@chromium.org,mstarzinger@google.com BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/9401008 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10759 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 08 Feb, 2012 1 commit
-
-
jkummerow@chromium.org authored
Review URL: https://chromiumcodereview.appspot.com/9221011 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10631 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 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
-
- 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
-
- 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 3 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
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
-