1. 11 Jul, 2012 1 commit
  2. 30 Apr, 2012 1 commit
  3. 12 Mar, 2012 1 commit
  4. 07 Dec, 2011 1 commit
    • keuchel@chromium.org's avatar
      Sync parser and preparser on do-while and return statements. · 410219c8
      keuchel@chromium.org authored
      This CL fixes the preparser to have the same liberal automatic semicolon
      insertion behaviour as the parser. In the case of a return statement in
      global code we throw a syntax error at runtime rather than an early error
      due to compatibility with KJS. However that hack allowed the following
      syntactically incorrect program in global code in the parser but not in
      the preparser:
        if (false) return else {}
      while the slightly saner version with the obligatory semicolon
        if (false) return; else {}
      was disallowed in the parser, but the preparser allowed it. This CL also
      fixes that issue.
      
      BUG=v8:1856
      TEST=cctest/test-parsing.cc
      
      Review URL: http://codereview.chromium.org/8844002
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10201 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      410219c8
  5. 29 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Make let/const outside of the extended mode early errors (under harmony flag). · e26093f3
      keuchel@chromium.org authored
      The ES.next drafts require that source code that matches the productions for
      let and const bindings outside the extended mode trigger early syntax
      errors. This CL adapts the parser / preparser accordingly under the harmony
      scoping flag.
      
      Summary:
      * Harmony scoping flag not set: Old semantics allowing const in classic mode
      with function level scope. Const binding in strict mode and let bindings in
      classic and strict mode trigger early syntax errors.
      * Harmony scoping is set: Use new harmony const and let in
      extended mode and old const in classic mode. This is to preserve
      compatibility with current web pages that already use
      non-standard implementations of const. An early syntax error is
      thrown on const in strict mode and on let in classic and strict
      mode.
      
      This depends on:
      http://codereview.chromium.org/8562002/
      
      TEST=mjsunit/harmony/block-early-errors.js
      
      Review URL: http://codereview.chromium.org/8564001
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10079 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      e26093f3
  6. 25 Nov, 2011 1 commit
  7. 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
  8. 01 Nov, 2011 1 commit
  9. 27 Oct, 2011 1 commit
  10. 25 Oct, 2011 1 commit
  11. 17 Oct, 2011 3 commits
  12. 12 Oct, 2011 1 commit
  13. 22 Sep, 2011 1 commit
  14. 21 Sep, 2011 1 commit
  15. 08 Sep, 2011 2 commits
  16. 07 Sep, 2011 1 commit
  17. 16 Aug, 2011 1 commit
  18. 12 Aug, 2011 1 commit
  19. 06 Jul, 2011 2 commits
  20. 05 Jul, 2011 1 commit
  21. 01 Jul, 2011 2 commits
  22. 24 Jun, 2011 1 commit
  23. 21 Jun, 2011 1 commit
  24. 20 Jun, 2011 1 commit
  25. 09 Jun, 2011 1 commit
  26. 24 May, 2011 1 commit
  27. 23 May, 2011 1 commit
  28. 19 May, 2011 2 commits
  29. 06 May, 2011 1 commit
  30. 29 Mar, 2011 1 commit
  31. 18 Mar, 2011 3 commits
  32. 07 Mar, 2011 1 commit