1. 26 Apr, 2013 6 commits
  2. 25 Apr, 2013 1 commit
  3. 24 Apr, 2013 3 commits
  4. 23 Apr, 2013 2 commits
  5. 22 Apr, 2013 1 commit
  6. 19 Apr, 2013 3 commits
  7. 18 Apr, 2013 3 commits
  8. 17 Apr, 2013 3 commits
  9. 16 Apr, 2013 2 commits
  10. 15 Apr, 2013 3 commits
  11. 12 Apr, 2013 3 commits
  12. 11 Apr, 2013 1 commit
  13. 10 Apr, 2013 1 commit
  14. 08 Apr, 2013 1 commit
  15. 05 Apr, 2013 2 commits
    • mstarzinger@chromium.org's avatar
      Refactor parser mode configuration for correctness · d7167867
      mstarzinger@chromium.org authored
      This patch refactors the parser and preparser interface to be more
      readable and type-safe.  It has no behavior changes.
      
      Previously, parsers and preparsers were configured via bitfield called
      parser_flags in the Parser constructor, and flags in
      PreParser::PreParseProgram, ParserApi::Parse, and ParserApi::PreParse.
      This was error-prone in practice: six call sites passed incorrectly
      typed values to this interface (a boolean FLAG value, a boolean false
      and a boolean true value).  None of these errors were caught by the
      compiler because it's just an "int".
      
      The parser flags interface was also awkward because it encoded a
      language mode, but the language mode was only used to turn on harmony
      scoping or not -- it wasn't used to actually set the parser's language
      mode.
      
      Fundamentally these errors came in because of the desire for a
      procedural parser interface, in ParserApi.  Because we need to be able
      to configure the parser in various ways, the flags argument got added;
      but no one understood how to use the flags properly.  Also they were
      only used by constructors: callers packed bits, and the constructors
      unpacked them into booleans on the parser or preparser.
      
      The solution is to allow parser construction, configuration, and
      invocation to be separated.  This patch does that.
      
      It passes the existing tests.
      
      BUG=
      
      Review URL: https://codereview.chromium.org/13450007
      Patch from Andy Wingo <wingo@igalia.com>.
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14151 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      d7167867
    • hpayer@chromium.org's avatar
      Refactoring BuildAllocateElements. · ff85f50e
      hpayer@chromium.org authored
      BUG=
      
      Review URL: https://codereview.chromium.org/13693004
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@14147 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      ff85f50e
  16. 04 Apr, 2013 2 commits
  17. 03 Apr, 2013 1 commit
  18. 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 Mar, 2013 1 commit