- 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
-
- 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
-
- 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
-