Commit Graph

3 Commits

Author SHA1 Message Date
rossberg@chromium.org
98db1a369d Implement proper module linking.
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
2012-07-09 08:59:03 +00:00
rossberg@chromium.org
ab26fb6b21 Implement rudimentary module linking.
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
2012-04-16 14:43:27 +00:00
rossberg@chromium.org
448b620dad Basic interface inference for modules.
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
2012-03-08 13:03:07 +00:00