1. 21 Oct, 2014 3 commits
  2. 16 Oct, 2014 1 commit
    • wingo@igalia.com's avatar
      Track usage of "this" and "arguments" in Scope · 0841f724
      wingo@igalia.com authored
      This adds flags in Scope to track wheter a Scope uses "this" and,
      "arguments". The information is exposed via Scope::uses_this(),
      and Scope::uses_arguments(), respectively. Flags for tracking
      usage on any inner scope uses are available as well via
      Scope::inner_uses_this(), and Scope::inner_uses_arguments().
      
      Knowing whether scopes use "this" and "arguments" will be handy
      to generate the code needed to capture their values when generating
      the code for arrow functions.
      
      BUG=v8:2700
      LOG=
      R=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/422923004
      
      Patch from Adrian Perez de Castro <aperez@igalia.com>.
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24663 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      0841f724
  3. 29 Sep, 2014 1 commit
  4. 18 Sep, 2014 1 commit
  5. 16 Sep, 2014 2 commits
  6. 10 Sep, 2014 2 commits
  7. 08 Sep, 2014 1 commit
  8. 02 Sep, 2014 1 commit
    • marja@chromium.org's avatar
      Refactor Parser to make it usable on a background thread. · 7955937d
      marja@chromium.org authored
      - Background Parsers cannot get the following data from Isolate (pass it to the
      ctor instead): stack limit (background Parsers need a different stack limit),
      UnicodeCache (background parsers need a separate UnicodeCache), hash seed
      (Parser cannot access the Heap to get it). The Parser::Parse API won't change.
      
      - Make the internalization phase (where Parser interacts with the heap) more
      explicit. Previously, Parser was interacting with the heap here and there.
      
      - Move HandleSourceURLComments out of DoParseProgram, so that background parsing
      can use DoParseProgram too.
      
      BUG=
      R=rossberg@chromium.org
      
      Review URL: https://codereview.chromium.org/527763002
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@23600 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      7955937d
  9. 26 Aug, 2014 1 commit
  10. 21 Aug, 2014 1 commit
  11. 20 Aug, 2014 1 commit
  12. 18 Aug, 2014 1 commit
  13. 07 Aug, 2014 1 commit
  14. 04 Aug, 2014 1 commit
  15. 30 Jul, 2014 1 commit
  16. 29 Jul, 2014 2 commits
  17. 21 Jul, 2014 1 commit
  18. 16 Jul, 2014 1 commit
    • vogelheim@chromium.org's avatar
      Change ScriptCompiler::CompileOptions to allow for two 'cache' modes · a42612b4
      vogelheim@chromium.org authored
      (parser or code) and to be explicit about cache consumption or production
      (rather than making presence of cached_data imply one or the other.)
      
      Also add a --cache flag to d8, to allow testing the functionality.
      
      -----------------------------
      API change
      
      Reason: Currently, V8 supports a 'parser cache' for repeatedly executing the same script. We'd like to add a 2nd mode that would cache code, and would like to let the embedder decide which mode they chose (if any).
      
      Note: Previously, the 'use cached data' property was implied by the presence of the cached data itself. (That is, kNoCompileOptions and source->cached_data != NULL.) That is no longer sufficient, since the presence of data is no longer sufficient to determine /which kind/ of data is present.
      
      Changes from old behaviour:
      
      - If you previously didn't use caching, nothing changes.
      Example:
        v8::CompileUnbound(isolate, source, kNoCompileOptions);
      
      - If you previously used caching, it worked like this:
      
        - 1st run:
        v8::CompileUnbound(isolate, source, kProduceToCache);
        Then, source->cached_data would contain the
        data-to-be cached. This remains the same, except you
        need to tell V8 which type of data you want.
        v8::CompileUnbound(isolate, source, kProduceParserCache);
      
        - 2nd run:
        v8::CompileUnbound(isolate, source, kNoCompileOptions);
        with source->cached_data set to the data you received in
        the first run. This will now ignore the cached data, and
        you need to explicitly tell V8 to use it:
        v8::CompileUnbound(isolate, source, kConsumeParserCache);
      -----------------------------
      
      BUG=
      R=marja@chromium.org, yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/389573006
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22431 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      a42612b4
  19. 15 Jul, 2014 1 commit
  20. 14 Jul, 2014 1 commit
    • marja@chromium.org's avatar
      Implement handling of arrow functions in the parser · 70da8959
      marja@chromium.org authored
      Arrow functions are parsed from ParseAssignmentExpression(). Handling the
      parameter list is done by letting ParseConditionalExpression() parse a comma
      separated list of identifiers, and it returns a tree of BinaryOperation nodes
      with VariableProxy leaves, or a single VariableProxy if there is only one
      parameter. When the arrow token "=>" is found, the VariableProxy nodes are
      passed to ParseArrowFunctionLiteral(), which will then skip parsing the
      paramaeter list. This avoids having to rewind when the arrow is found and
      restart parsing the parameter list.
      
      Note that the empty parameter list "()" is handled directly in
      ParsePrimaryExpression(): after is has consumed the opening parenthesis,
      if a closing parenthesis follows, then the only valid input is an arrow
      function. In this case, ParsePrimaryExpression() directly calls
      ParseArrowFunctionLiteral(), to avoid needing to return a sentinel value
      to signal the empty parameter list. Because it will consume the body of
      the arrow function, ParseAssignmentExpression() will not see the arrow
      "=>" token as next, and return the already-parser expression.
      
      The implementation is done in ParserBase, so it was needed to do some
      additions to ParserBase, ParserTraits and PreParserTraits. Some of the
      glue code can be removed later on when more more functionality is moved
      to ParserBase.
      
      Additionally, this adds a runtime flag "harmony_arrow_functions"
      (disabled by default); enabling "harmony" will enable it as well.
      
      BUG=v8:2700
      LOG=N
      R=marja@chromium.org
      
      Review URL: https://codereview.chromium.org/383983002
      
      Patch from Adrián Pérez de Castro <aperez@igalia.com>.
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22366 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      70da8959
  21. 11 Jul, 2014 1 commit
  22. 10 Jul, 2014 4 commits
  23. 08 Jul, 2014 2 commits
    • marja@chromium.org's avatar
      Revert "Implement handling of arrow functions in the parser" · c393b9a5
      marja@chromium.org authored
      This reverts r22265.
      
      Reason: ASAN tests fail.
      
      BUG=
      TBR=marja@chromium.org,aperez@igalia.com
      
      Review URL: https://codereview.chromium.org/372983003
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22266 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      c393b9a5
    • marja@chromium.org's avatar
      Implement handling of arrow functions in the parser · 7367720d
      marja@chromium.org authored
      Arrow functions are parsed from ParseAssignmentExpression. Handling the
      parameter list is done by letting ParseConditionalExpression() parse
      a comma-separated list of identifiers, and it returns a tree of
      BinaryOperation nodes with VariableProxy leaves, or a single
      VariableProxy if there is only one parameter. When the arrow token "=>"
      is found, the VariableProxy nodes are passed to ParseFunctionLiteral(),
      which will then skip parsing the paramaeter list. This avoids having
      to rewind when the arrow is found and restart parsing the parameter
      list. Note that ParseExpression() expects parenthesized expressions
      to not be empty, so checking for a closing parenthesis is added in
      handling the empty parameter list "()" will accept a right-paren and
      return an empty expression, which means that the parameter list is
      empty.
      
      Additionally, this adds the following machinery:
      
       - A runtime flag "harmony_arrow_functions" (disabled by default).
         Enabling "harmony" will enable it as well.
       - An IsArrow bit in SharedFunctionInfo, and accessors for it.
       - An IsArrow bit in FunctionLiteral, accessorts for it, and
         a constructor parameter to set its value.
       - In ParserBase: allow_arrow_functions() and set_allow_arrow_functions()
       - A V8 native %FunctionIsArrow(), which is used to skip adding the
         "function " prefix when getting the source code for an arrow
         function.
      
      R=marja@chromium.org
      
      Review URL: https://codereview.chromium.org/160073006
      
      Patch from Adrián Pérez de Castro <aperez@igalia.com>.
      
      git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22265 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      7367720d
  24. 03 Jul, 2014 1 commit
  25. 02 Jul, 2014 2 commits
  26. 30 Jun, 2014 2 commits
  27. 26 Jun, 2014 1 commit
  28. 25 Jun, 2014 1 commit
  29. 24 Jun, 2014 1 commit