- 30 Sep, 2015 1 commit
-
-
mstarzinger authored
This enables linter checking for "readability/namespace" violations during presubmit and instead marks the few known exceptions that we allow explicitly. R=bmeurer@chromium.org Review URL: https://codereview.chromium.org/1371083003 Cr-Commit-Position: refs/heads/master@{#31019}
-
- 09 Apr, 2015 1 commit
-
-
adamk authored
BUG=v8:1569 LOG=n Review URL: https://codereview.chromium.org/1078903002 Cr-Commit-Position: refs/heads/master@{#27724}
-
- 27 Feb, 2015 1 commit
-
-
adamk authored
This required fixing the exports_ hash map to use the appropriate comparison function instead of pointer comparison. BUG=v8:1569 LOG=n Review URL: https://codereview.chromium.org/960793003 Cr-Commit-Position: refs/heads/master@{#26920}
-
- 19 Feb, 2015 1 commit
-
-
adamk authored
Add() becomes AddLocalExport, which takes an export_name and a local_name. New parsing tests exercise this. Also start generating exports for default exports (though this doesn't yet handle anonymous default exports). BUG=v8:1569 LOG=n Review URL: https://codereview.chromium.org/934323004 Cr-Commit-Position: refs/heads/master@{#26758}
-
- 18 Feb, 2015 1 commit
-
-
adamk authored
ModuleDescriptor will end up holding the set of data described in the spec as a "Module record". This introduces a little bit of confusion with ModuleInfo, but I hope that'll become clearer over time. Also removed the interface-printing flags. We probably want Module-printing flags, but that can wait until we have more Module-related structures. BUG=v8:1569 LOG=n Review URL: https://codereview.chromium.org/935723004 Cr-Commit-Position: refs/heads/master@{#26728}
-
- 17 Feb, 2015 1 commit
-
-
adamk authored
This gets Variable and VariableProxy out of the business of worrying about Interfaces. At the same time, get rid of the notion of "module variables". In ES6, variables that refer to modules will be simply be CONST bindings to module namespace objects. The only change in logic here is one more early error: duplicate export names are now rejected. BUG=v8:1569 LOG=n Review URL: https://codereview.chromium.org/918373002 Cr-Commit-Position: refs/heads/master@{#26708}
-
- 29 Jan, 2015 1 commit
-
-
bmeurer authored
R=svenpanne@chromium.org Review URL: https://codereview.chromium.org/885813002 Cr-Commit-Position: refs/heads/master@{#26315}
-
- 12 Nov, 2014 1 commit
-
-
dslomov@chromium.org authored
1. Global{Context,Scope}=>Script{Context,Scope} 2. Enable fixed tests 3. Update comments R=rossberg@chromium.org BUG=v8:2198 LOG=N Review URL: https://codereview.chromium.org/716833002 Cr-Commit-Position: refs/heads/master@{#25291} git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@25291 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
- 21 Oct, 2014 2 commits
-
-
rossberg@chromium.org authored
(I'm puzzled why GCC did not report this error.) TBR=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/669733007 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24776 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
-
rossberg@chromium.org authored
R=bmeurer@chromium.org BUG=421634 LOG=N Review URL: https://codereview.chromium.org/667703002 git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24774 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
-
- 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
-
- 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
-
- 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
-
- 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
-
- 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
-
- 16 Apr, 2012 1 commit
-
-
rossberg@chromium.org authored
Constructs the (generally cyclic) graph of module instance objects and populates their exports. Any exports other than nested modules are currently set to 'undefined' (but already present as properties). Details: - Added new type JSModule for instance objects: a JSObject carrying a context. - Statically allocate instance objects for all module literals (in parser 8-}). - Extend interfaces to record and unify concrete instance objects, and to support iteration over members. - Introduce new runtime function for pushing module contexts. - Generate code for allocating, initializing, and setting module contexts, and for populating instance objects from module literals. Currently, all non-module exports are still initialized with 'undefined'. - Module aliases are resolved statically, so no special code is required. - Make sure that code containing module constructs is never optimized (macrofy AST node construction flag setting while we're at it). - Add test case checking linkage. Baseline: http://codereview.chromium.org/9722043/ R=svenpanne@chromium.org,mstarzinger@chromium.org BUG= TEST= Review URL: https://chromiumcodereview.appspot.com/9844002 git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@11336 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
-