1. 19 Sep, 2014 1 commit
  2. 04 Aug, 2014 1 commit
  3. 30 Jul, 2014 1 commit
  4. 30 Jun, 2014 1 commit
  5. 26 Jun, 2014 1 commit
  6. 24 Jun, 2014 1 commit
  7. 18 Jun, 2014 1 commit
  8. 13 Jun, 2014 1 commit
  9. 03 Jun, 2014 1 commit
  10. 22 May, 2014 1 commit
  11. 29 Apr, 2014 1 commit
  12. 11 Mar, 2014 2 commits
  13. 06 Jun, 2013 1 commit
  14. 05 Apr, 2013 1 commit
    • mstarzinger@chromium.org's avatar
      Force context allocation for variables in generator scopes. · b6efbd79
      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
      b6efbd79
  15. 18 Dec, 2012 1 commit
  16. 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
  17. 05 Oct, 2012 1 commit
  18. 27 Aug, 2012 1 commit
  19. 17 Aug, 2012 1 commit
  20. 13 Jul, 2012 1 commit
  21. 09 Jul, 2012 1 commit
    • rossberg@chromium.org's avatar
      Implement proper module linking. · 98db1a36
      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
      98db1a36
  22. 03 Jul, 2012 1 commit
  23. 19 Jun, 2012 1 commit
  24. 13 Jun, 2012 1 commit
  25. 12 Jun, 2012 1 commit
  26. 11 Jun, 2012 1 commit
  27. 18 May, 2012 1 commit
  28. 16 Apr, 2012 1 commit
  29. 08 Mar, 2012 1 commit
  30. 29 Feb, 2012 1 commit
  31. 23 Feb, 2012 1 commit
  32. 20 Feb, 2012 1 commit
  33. 08 Feb, 2012 1 commit
  34. 05 Dec, 2011 1 commit
  35. 24 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Introduce extended mode. · 1e9a7267
      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
      1e9a7267
  36. 15 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Static resolution of outer variables in eval code. · 08c9629f
      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
      08c9629f
  37. 03 Nov, 2011 3 commits