1. 12 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Generate correct locations for error messages · 222541df
      clemensh authored
      The current logic in Isolate::GetLocationFromStackTrace just ignores
      wasm frames, making the computed location point to the first javascript
      frame, like this:
      
      test.js:17: RuntimeError: divide by zero
      module.exports.main();
                     ^
      RuntimeError: divide by zero
          at main (<WASM>[1]+5)
          at test.js:17:16
      
      This CL not only fixes the location to point to the top-most wasm
      frame, but also exposes to the embedder that the script of that location
      is a wasm script, allowing for custom printing of wasm locations.
      The Shell::ReportException method now checks for this flag, and prints
      wasm locations like this:
      
      <WASM>[0]+5: RuntimeError: divide by zero
      RuntimeError: divide by zero
          at main (<WASM>[0]+5)
          at test/message/wasm-trap.js:15:16
      
      R=titzer@chromium.org, yangguo@chromium.org
      BUG=chromium:613110
      
      Review-Url: https://codereview.chromium.org/2563673002
      Cr-Commit-Position: refs/heads/master@{#41640}
      222541df
  2. 08 Dec, 2016 1 commit
  3. 07 Dec, 2016 1 commit
    • jwolfe's avatar
      Change error messages for octal escape sequences · 089e4fd3
      jwolfe authored
      When an octal escape sequence is in a string in strict mode:
      - Octal literals are not allowed in strict mode.
      + Octal escape sequences are not allowed in strict mode.
      
      When an octal escape sequence is in a template string:
      - Octal literals are not allowed in template strings.
      + Octal escape sequences are not allowed in template strings.
      
      BUG=v8:4973
      CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
      
      Review-Url: https://codereview.chromium.org/2551633002
      Cr-Commit-Position: refs/heads/master@{#41560}
      089e4fd3
  4. 29 Nov, 2016 1 commit
  5. 24 Nov, 2016 1 commit
  6. 23 Nov, 2016 2 commits
  7. 18 Nov, 2016 1 commit
    • marja's avatar
      Remove FLAG_min_preparse_length. · 4a5b7e32
      marja authored
      It originates from the era where we used to run a separate preparse step
      before parsing and store the function data. Now the usage of preparser
      is something completely different, so this flag doesn't make sense any
      more.
      
      In addition, this way we get more test coverage for preparser (for small
      scripts).
      
      BUG=
      
      Review-Url: https://codereview.chromium.org/2513563002
      Cr-Commit-Position: refs/heads/master@{#41110}
      4a5b7e32
  8. 27 Oct, 2016 1 commit
  9. 26 Oct, 2016 1 commit
  10. 28 Sep, 2016 1 commit
  11. 15 Sep, 2016 1 commit
  12. 14 Sep, 2016 2 commits
  13. 07 Sep, 2016 1 commit
  14. 31 Aug, 2016 1 commit
  15. 29 Aug, 2016 1 commit
    • littledan's avatar
      Disallow tail calls from async functions and generators · 5af4cd98
      littledan authored
      Tail calls don't make sense from async functions and generators, as
      each activation of these functions needs to make a new, distnict,
      non-reused generator object. These tail calls are not required per
      spec. This patch disables both syntactic and implicit tail calls
      in async functions and generators.
      
      R=neis
      BUG=v8:5301,chromium:639270
      
      Review-Url: https://codereview.chromium.org/2278413003
      Cr-Commit-Position: refs/heads/master@{#38986}
      5af4cd98
  16. 25 Jul, 2016 1 commit
  17. 12 Jul, 2016 1 commit
  18. 04 Jul, 2016 1 commit
    • jgruber's avatar
      [builtins] Add receiver to builtin exit frames · f59a2335
      jgruber authored
      Stack trace generation requires access to the receiver; and while the
      receiver is already on the stack, we cannot determine its position
      during stack trace generation (it's stored in argv[0], and argc is only
      stored in a callee-saved register).
      
      This patch grants access to the receiver by pushing argc onto builtin
      exit frames as an extra argument. Compared to simply pushing the
      receiver, this requires an additional dereference during stack trace
      generation, but one fewer during builtin calls.
      
      BUG=v8:4815
      
      Review-Url: https://codereview.chromium.org/2106883003
      Cr-Commit-Position: refs/heads/master@{#37500}
      f59a2335
  19. 30 Jun, 2016 1 commit
    • jgruber's avatar
      [builtins] New frame type for exits to C++ builtins · 5febc27b
      jgruber authored
      Prior to this commit, calls to C++ builtins created standard exit
      frames, which are skipped when constructing JS stack traces. In order to
      show these calls on traces, we introduce a new builtin exit frame type.
      
      Builtin exit frames contain target and new.target on the stack and are
      not skipped during stack trace construction.
      
      BUG=v8:4815
      R=bmeurer@chromium.org, yangguo@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel;tryserver.v8:v8_linux_nosnap_dbg
      
      Committed: https://crrev.com/3c60c6b105f39344f93a8407f41534e5e60cf19a
      Review-Url: https://codereview.chromium.org/2090723005
      Cr-Original-Commit-Position: refs/heads/master@{#37384}
      Cr-Commit-Position: refs/heads/master@{#37416}
      5febc27b
  20. 29 Jun, 2016 2 commits
  21. 24 Jun, 2016 1 commit
  22. 30 May, 2016 1 commit
  23. 20 May, 2016 1 commit
  24. 10 May, 2016 1 commit
  25. 09 May, 2016 1 commit
  26. 04 May, 2016 1 commit
    • ishell's avatar
      [es8] More spec compliant syntactic tail calls implementation. · 1350eb3d
      ishell authored
      Unlike previous implementation where the 'continue' keyword was a feature of a return statement the keyword is now recognized as a part of expression. Error reporting was significantly improved.
      
      --harmony-explicit-tailcalls option is now orthogonal to --harmony-tailcalls so we can test both modes at the same time.
      
      This CL also adds %GetExceptionDetails(exception) that fetches hidden |start_pos| and |end_pos| values from the exception object.
      
      BUG=v8:4915
      LOG=N
      
      Review-Url: https://codereview.chromium.org/1928203002
      Cr-Commit-Position: refs/heads/master@{#36024}
      1350eb3d
  27. 03 May, 2016 1 commit
    • adamk's avatar
      Properly disallow 'yield' in class expressions and arrow parameters · 9e9abcff
      adamk authored
      Yield expressions are not allowed in formal parameter initializers of
      generators, but we weren't properly catching the case where the yield
      expression appeared in the 'extends' clause of a class expression.
      
      They also aren't allowed in arrow functions, which we were failing to
      catch due to not looking at the obscurely-named "FormalParameterInitializerError"
      bit of ExpressionClassifier.
      
      This patch passes along an ExpressionClassifier when parsing class
      expressions and accumulates the proper error for that case.
      
      For the arrow function case, the fix is simply to check for the
      "formal parameter initializer" error once we know we've parsed
      an arrow function. The error message used for this has also
      been made specific to yield expressions.
      
      Tests are added both for the error case and the non-error cases (where
      yield is used in such a position inside the class body).
      
      BUG=v8:4966, v8:4968, v8:4974
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1941823003
      Cr-Commit-Position: refs/heads/master@{#35957}
      9e9abcff
  28. 29 Apr, 2016 1 commit
  29. 27 Apr, 2016 1 commit
  30. 26 Apr, 2016 1 commit
  31. 08 Apr, 2016 1 commit
  32. 04 Apr, 2016 2 commits
    • yangguo's avatar
      [interpreter] add some expression positions. · f7e7ba11
      yangguo authored
      Statement positions should overwrite expression positions if they
      have the same bytecode offset.
      
      R=mstarzinger@chromium.org, vogelheim@chromium.org
      BUG=v8:4680,v8:4689
      LOG=N
      
      Review URL: https://codereview.chromium.org/1855913002
      
      Cr-Commit-Position: refs/heads/master@{#35236}
      f7e7ba11
    • neis's avatar
      Preserve exception message in iterator finalization. · f70b3d3b
      neis authored
      The parser uses a try-catch in order to record when the client of an iterator
      throws.  The exception then used to get rethrown via 'throw', which
      unfortunately resulted in the original exception message object getting
      overwritten.
      
      This CL solves this as follows:
      - add a clear_pending_message flag to TryCatchStatement (set to true in normal
        cases),
      - set clear_pending_message to false for the TryCatchStatement used in iterator
        finalization
      - change full-codegen, turbofan, and the interpreter to emit the ClearPendingMessage call
        only when the flag is set,
      - replace 'throw' with '%ReThrow' in the iterator finalization code, thus
        reusing the (not-cleared) pending message
      
      R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
      BUG=v8:4875
      LOG=n
      
      Review URL: https://codereview.chromium.org/1842953003
      
      Cr-Commit-Position: refs/heads/master@{#35226}
      f70b3d3b
  33. 22 Mar, 2016 1 commit
    • adamk's avatar
      Remove support for legacy const, part 1 · ed18aa65
      adamk authored
      Now that ES2015 const has shipped, in Chrome 49, legacy const declarations
      are no more. This lets us remove a bunch of code from many parts of the
      codebase.
      
      In this patch, I remove parser support for generating legacy const variables
      from const declarations. This also removes the special "illegal declaration"
      bit from Scope, which has ripples into all compiler backends.
      
      Also gone are any tests which relied on legacy const declarations.
      
      Note that we do still generate a Variable in mode CONST_LEGACY in one case:
      function name bindings in sloppy mode. The likely fix there is to add a new
      Variable::Kind for this case and handle it appropriately for stores in each
      backend, but I leave that for a later patch to make this one completely
      subtractive.
      
      Review URL: https://codereview.chromium.org/1819123002
      
      Cr-Commit-Position: refs/heads/master@{#35002}
      ed18aa65
  34. 21 Mar, 2016 2 commits
  35. 18 Mar, 2016 1 commit