1. 16 Feb, 2012 1 commit
  2. 14 Feb, 2012 2 commits
  3. 08 Feb, 2012 1 commit
  4. 31 Jan, 2012 1 commit
  5. 27 Jan, 2012 3 commits
  6. 24 Jan, 2012 1 commit
  7. 23 Jan, 2012 1 commit
  8. 17 Jan, 2012 1 commit
  9. 16 Jan, 2012 1 commit
  10. 13 Jan, 2012 1 commit
  11. 11 Jan, 2012 4 commits
  12. 09 Jan, 2012 1 commit
  13. 04 Jan, 2012 2 commits
  14. 23 Dec, 2011 1 commit
  15. 22 Dec, 2011 1 commit
  16. 20 Dec, 2011 1 commit
  17. 13 Dec, 2011 1 commit
  18. 09 Dec, 2011 1 commit
  19. 07 Dec, 2011 3 commits
  20. 06 Dec, 2011 3 commits
  21. 02 Dec, 2011 1 commit
  22. 01 Dec, 2011 2 commits
  23. 29 Nov, 2011 1 commit
  24. 25 Nov, 2011 1 commit
  25. 24 Nov, 2011 3 commits
    • 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
    • mstarzinger@chromium.org's avatar
      Implement crankshaft support for nested object literals. · 7e7d4dfd
      mstarzinger@chromium.org authored
      This generates optimized code for deep-copying of nested object literal
      boilerplates which are statically known. Most of the boilerplates have
      already been generated at crankshaft time, so this optimization should
      kick in for virtually every object literal. Only nested object literal
      graphs up to a certain depth and containing up to a certain total number
      of properties are considered for this optimization. This will prevent
      explosion of code size due to large object literals (e.g. eval on JSON).
      Improves splay performance because object literals are created often.
      
      R=fschneider@chromium.org
      
      Review URL: http://codereview.chromium.org/8640001
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10061 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      7e7d4dfd
    • yangguo@chromium.org's avatar
  26. 23 Nov, 2011 1 commit