1. 20 May, 2016 1 commit
  2. 17 May, 2016 1 commit
    • bmeurer's avatar
      [es6] Reintroduce the instanceof operator in the backends. · 551e0aa1
      bmeurer authored
      This adds back the instanceof operator support in the backends and
      introduces a @@hasInstance protector cell on the isolate that guards the
      fast path for the InstanceOfStub. This way we recover the ~10%
      regression on Octane EarleyBoyer in Crankshaft and greatly improve
      TurboFan and Ignition performance of instanceof.
      
      R=ishell@chromium.org
      TBR=hpayer@chromium.org,rossberg@chromium.org
      BUG=chromium:597249, v8:4447
      LOG=n
      
      Review-Url: https://codereview.chromium.org/1980483003
      Cr-Commit-Position: refs/heads/master@{#36275}
      551e0aa1
  3. 16 May, 2016 1 commit
  4. 10 May, 2016 1 commit
  5. 09 May, 2016 1 commit
  6. 06 May, 2016 1 commit
    • clemensh's avatar
      [wasm] Make wasm info available on the stack trace · a4cd1eef
      clemensh authored
      This changes different locations to extract the reference to the wasm
      object and the function index from the stack trace, and make it
      available through all the APIs which process stack traces.
      The javascript CallSite object now has the new methods isWasm(),
      getWasmObject() and getWasmFunctionIndex(); the byte offset is
      available via getPosition().
      
      Function names of wasm frames should be fully functional with this
      commit, position information works reliably for calls, but not for
      traps like unreachable or out-of-bounds accesses.
      
      R=titzer@chromium.org, yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/1909353002
      Cr-Commit-Position: refs/heads/master@{#36067}
      a4cd1eef
  7. 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
  8. 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
  9. 28 Apr, 2016 1 commit
  10. 27 Apr, 2016 2 commits
  11. 26 Apr, 2016 1 commit
  12. 22 Apr, 2016 1 commit
  13. 19 Apr, 2016 2 commits
    • clemensh's avatar
      Move TrapReason messages over to messages.h · ce669d79
      clemensh authored
      This prepares a patch to throw actual errors instead of just strings on
      wasm traps. In order to accomplish this, the messages need to be known
      to the runtime, as the generated code will just pass the message id.
      
      R=mstarzinger@chromium.org, titzer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1880493002
      
      Cr-Commit-Position: refs/heads/master@{#35628}
      ce669d79
    • clemensh's avatar
      Move MessageLocations constructor out of header · e2ec04d2
      clemensh authored
      This is a bit unfortunate, but otherwise we would have to include
      objects.h before message.h, since for the initialization of a Handle<T>,
      the compiler checks that Object* can be assigned to T*. So it would
      need to know about the inheritance for initializing Handle<Script> and
      Handle<JSFunction>.
      
      R=mstarzinger@chromium.org, titzer@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1872373002
      
      Cr-Commit-Position: refs/heads/master@{#35626}
      e2ec04d2
  14. 08 Apr, 2016 1 commit
  15. 25 Mar, 2016 2 commits
  16. 24 Mar, 2016 2 commits
    • littledan's avatar
      Add ES2015 RegExp full subclassing semantics behind a flag · 92a571e5
      littledan authored
      This patch implements ES2015 RegExp subclassing semantics, namely the
      hardest part where RegExp.prototype.exec and certain flag getters can
      be overridden in order to provide different behavior. This change is
      hidden behind a new flag, --harmony-regexp-exec. The flag guards the
      behavior by installing entirely different implementations of the
      methods which follow the new semantics.
      
      Preliminary performance tests show a 3-4x regression in the Octane
      RegExp benchmark. The new code doesn't call out into several fast
      paths that the old code supported, so this is expected.
      
      The patch is tested mostly by test262, where most RegExp tests are fixed,
      with the exception of deliberate spec violations for web compatibility,
      and for the 'sticky' flag, which is not dynamically read by this patch
      in all cases but rather statically compiled into the RegExp. The latter
      will require a follow-on patch to implement. A small additional set of
      tests verifies one particular case, mostly to check whether the flag
      mechanism works.
      
      R=adamk,yangguo@chromium.org
      LOG=Y
      BUG=v8:4602
      
      Review URL: https://codereview.chromium.org/1596483005
      
      Cr-Commit-Position: refs/heads/master@{#35068}
      92a571e5
    • littledan's avatar
      Implement ES2015 labelled function declaration restrictions · 7f108b65
      littledan authored
      ES#sec-islabelledfunction specifies that labelled function declarations
      may not occur as the body of a control flow construct such as an if
      statement. This patch implements those restrictions, which also
      eliminates a previous case resulting in a DCHECK failure which is now
      a SyntaxError.
      
      BUG=chromium:595309
      R=adamk
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1808373003
      
      Cr-Commit-Position: refs/heads/master@{#35049}
      7f108b65
  17. 21 Mar, 2016 2 commits
  18. 18 Mar, 2016 1 commit
  19. 10 Mar, 2016 2 commits
  20. 03 Mar, 2016 1 commit
    • littledan's avatar
      Restrict FunctionDeclarations in Statement position · 0e7f095c
      littledan authored
      ES2015 generally bans FunctionDeclarations in positions which expect a Statement,
      as opposed to a StatementListItem, such as a FunctionDeclaration which constitutes
      the body of a for loop. However, Annex B 3.2 and 3.4 make exceptions for labeled
      function declarations and function declarations as the body of an if statement in
      sloppy mode, in the latter case specifying that the semantics are as if the
      function declaration occurred in a block. Chrome has historically permitted
      further extensions, for the body of any flow control construct.
      
      This patch addresses both the syntactic and semantic mismatches between V8 and
      the spec. For the semantic mismatch, function declarations as the body of if
      statements change from unconditionally hoisting in certain cases to acquiring
      the sloppy mode function in block semantics (based on Annex B 3.3). For the
      extra syntax permitted, this patch adds a flag,
      --harmony-restrictive-declarations, which excludes disallowed function declaration
      cases. A new UseCounter, LegacyFunctionDeclaration, is added to count how often
      function declarations occur as the body of other constructs in sloppy mode. With
      this patch, the code generally follows the form of the specification with respect
      to parsing FunctionDeclarations, rather than allowing them in arbitrary Statement
      positions, and makes it more clear where our extensions occur.
      
      BUG=v8:4647
      R=adamk
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1757543003
      
      Cr-Commit-Position: refs/heads/master@{#34470}
      0e7f095c
  21. 02 Mar, 2016 1 commit
  22. 01 Mar, 2016 2 commits
    • littledan's avatar
      Make RUNTIME_ASSERT have more useful output in debug mode · 78d84530
      littledan authored
      Runtime asserts are were previously a bit annoying to debug, due to
      the lack of a useful error message, even in debug mode. This patch
      prints out some more information in debug mode for runtime assert
      failures while preserving their exception-throwing semantics. While
      we're at it, it requires a semicolon after RUNTIME_ASSERT macro
      invocations.
      
      ```
      $ rlwrap out/Debug/d8 --allow-natives-syntax
      V8 version 5.1.0 (candidate)
      d8> %ArrayBufferNeuter(1)
      
      #
      # Runtime error in ../../src/runtime/runtime-typedarray.cc, line 52
      #
      # args[0]->IsJSArrayBuffer()
      
      ==== C stack trace ===============================
      
       1: 0xf70ab5
       2: 0xadeebf
       3: 0xadedd4
       4: 0x2ef17630693b
      (d8):1: illegal access
      %ArrayBufferNeuter(1)
      ^
      
      d8>
      ```
      
      Also give the other 'illegal access' case (a special SyntaxError type) a more
      descriptive error message for its sole usage.
      
      R=adamk
      
      Review URL: https://codereview.chromium.org/1748183002
      
      Cr-Commit-Position: refs/heads/master@{#34401}
      78d84530
    • mstarzinger's avatar
      Remove the global Strength enum class completely. · 00e9447a
      mstarzinger authored
      R=bmeurer@chromium.org
      BUG=v8:3956
      LOG=n
      
      Review URL: https://codereview.chromium.org/1731063007
      
      Cr-Commit-Position: refs/heads/master@{#34398}
      00e9447a
  23. 29 Feb, 2016 1 commit
  24. 26 Feb, 2016 1 commit
  25. 19 Feb, 2016 1 commit
  26. 18 Feb, 2016 4 commits
  27. 16 Feb, 2016 1 commit
  28. 10 Feb, 2016 1 commit
  29. 04 Feb, 2016 2 commits