Skip to content

V
V8
Switch branch/tag
  1. 14 Oct, 2013 1 commit
  3. 01 Oct, 2013 1 commit
  5. 30 Sep, 2013 2 commits
  7. 02 Sep, 2013 1 commit
  9. 24 Jun, 2013 1 commit
  11. 06 Jun, 2013 1 commit
  13. 08 May, 2013 2 commits
  15. 16 Apr, 2013 1 commit
  17. 02 Apr, 2013 1 commit
    • mstarzinger@chromium.org's avatar
      Add parser support for generators. · 2816f196
      mstarzinger@chromium.org authored 
      This patchset begins by adding support for "yield", which is unlike other tokens
in JS. In a generator, whether strict or classic, it is a syntactic keyword.
In classic mode it is an identifier. In strict mode it is reserved.

This patch adds YIELD as a token to the scanner, and adapts the preparser and
parser appropriately. It also parses "function*", indicating that a function is
actually a generator, for both eagerly and lazily parsed functions.

Currently "yield" just compiles as "return".

BUG=v8:2355
TEST=mjsunit/harmony/generators-parsing

Review URL: https://codereview.chromium.org/12646003
Patch from Andy Wingo <wingo@igalia.com>.

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14116 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      2816f196
  19. 28 Feb, 2013 1 commit
  21. 18 Dec, 2012 1 commit
  23. 10 Dec, 2012 1 commit
  25. 05 Dec, 2012 1 commit
  27. 03 Dec, 2012 2 commits
  29. 30 Nov, 2012 2 commits
  31. 22 Nov, 2012 1 commit
    • rossberg@chromium.org's avatar
      Get rid of static module allocation, do it in code. · ce05280b
      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
      ce05280b
  33. 29 Feb, 2012 1 commit
  35. 28 Feb, 2012 1 commit
  37. 20 Feb, 2012 1 commit
  39. 09 Feb, 2012 2 commits
  41. 08 Feb, 2012 1 commit
  43. 16 Dec, 2011 1 commit
  45. 15 Sep, 2011 1 commit
    • svenpanne@chromium.org's avatar
      Nuke CompareToNull AST node. · 8c744768
      svenpanne@chromium.org authored 
      The Great Master Plan is to move the recognition of special cases for
comparisons further down the compilation pipeline where more information is
available. This is a first step into this direction: The special handling of
equality comparisons involving null is pushed from the parser to the code
generators, removing the need for a special AST node. (There are rumors from
usually well-informed sources that this node type is actually a relic of ancient
crankshaft days...)

The next steps will be the unification of null/undefined handling and pushing
the special case handling in crankshaft even further down the pipeline, enabling
the recognition of cases like "var foo=null; if (foo === bar) ...", but these
will be in separate CLs.
Review URL: http://codereview.chromium.org/7887037

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9293 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      8c744768
  47. 12 Sep, 2011 1 commit
  49. 09 Sep, 2011 1 commit
  51. 08 Sep, 2011 1 commit
  53. 07 Sep, 2011 1 commit
  55. 12 Aug, 2011 1 commit
  57. 30 Jun, 2011 1 commit
  59. 16 Jun, 2011 2 commits
  61. 15 Jun, 2011 1 commit
  63. 09 Jun, 2011 1 commit
  65. 08 Jun, 2011 1 commit
  67. 23 May, 2011 1 commit