1. 24 Aug, 2016 2 commits
    • littledan's avatar
      Do not trigger ExceptionEvents for another forwarding case · aae17eb3
      littledan authored
      This patch fixes up one last case of redundant ExceptionEvents being
      triggered in the debugger for Promises--it makes the default reject
      handler for Promises (e.g., if the second argument for
      Promise.prototype.then is missing) appear to the debugger as a
      rethrow.
      
      R=adamk@chromium.org,jgruber@chromium.org
      BUG=v8:5167
      
      Review-Url: https://codereview.chromium.org/2278643002
      Cr-Commit-Position: refs/heads/master@{#38876}
      aae17eb3
    • littledan's avatar
      Change which ExceptionEvents are triggered by Promises · 013e49f7
      littledan authored
      To make async/await catch prediction work well, this patch regularizes
      the exception events sent to DevTools from various places in the Promise
      lifecycle. The core is that there should be an exception event when the
      rejection first starts, rather than when it is propagated.
      
      - Several cases within Promise code which propagate errors are
        modified to not trigger a new ExceptionEvent in that case, such
        as .then on a rejected Promise and returning a rejected Promise
        from .then, as well as Promise.race and Promise.all.
      - Make Promise.reject() create an ExceptionEvent, subject to catch
        prediction based on the Promise stack. This is important
        so that, e.g., if "await Promise.reject()" will trigger a new
        throw (rather than a silent rethrow of something that never
        triggered an event in the first place).
      
      BUG=v8:5167
      
      Review-Url: https://codereview.chromium.org/2244003003
      Cr-Commit-Position: refs/heads/master@{#38847}
      013e49f7
  2. 22 Aug, 2016 1 commit
  3. 17 Aug, 2016 1 commit
  4. 10 Aug, 2016 1 commit
  5. 02 Aug, 2016 2 commits
  6. 01 Aug, 2016 1 commit
    • cbruni's avatar
      [keys] Trigger [[getOwnPropertyDescriptor]] trap on proxies for Object.keys · f4f06c50
      cbruni authored
      This CL fixes a long-standing bug with Object.keys where the enumerability
      check was omitted if the [ownKeys] trap is not present. The only distinction the
      KeyAccumulator needs is whether it collects keys for for-in (is_for_in_) or not.
      ForInFilter performs a separate step to filter out non-enumerable keys later-on
      while in all the other use-cases we have to filter keys.
      
      BUG=v8:1543, v8:5250
      
      Review-Url: https://codereview.chromium.org/2176113009
      Cr-Commit-Position: refs/heads/master@{#38199}
      f4f06c50
  7. 28 Jul, 2016 1 commit
  8. 25 Jul, 2016 2 commits
  9. 22 Jul, 2016 3 commits
    • caitp's avatar
      [builtins] take slow path in IsConcatSpreadable if proxy in prototype · 122a9b7a
      caitp authored
      BUG=v8:5134
      R=cbruni@chromium.org, littledan@chromium.org, neis@chromium.org
      
      Review-Url: https://codereview.chromium.org/2131383002
      Cr-Commit-Position: refs/heads/master@{#37987}
      122a9b7a
    • yangguo's avatar
      [debug] use catch prediction flag for promise rejections. · 6d0a4202
      yangguo authored
      This is in preparation to implementing exception prediction for async
      functions.  Each handler table entry can now predict "caught", "uncaught", or
      "promise". The latter indicates that the exception will lead to a promise
      rejection.
      
      To mark the relevant try-catch blocks, we add a new native syntax.
      try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
      prediction.
      
      The previous implementation of using the function to tell the relevant
      try-catch apart from inner try-catch blocks will not work for async functions
      since these can have inner try-catch blocks inside the same function.
      
      BUG=v8:5167
      
      Review-Url: https://codereview.chromium.org/2161263003
      Cr-Commit-Position: refs/heads/master@{#37966}
      6d0a4202
    • jwolfe's avatar
      Adjust whitespace to make tests oblivious to --harmony-function-tostring · 3cfd80d6
      jwolfe authored
      See discussion in https://codereview.chromium.org/2156303002/#msg8
      
      With the new --harmony-function-tostring behavior, these tests would
      fail without this change. This change makes the tests pass regardless
      of whether or not --harmony-function-tostring is used.
      
      All of these changes are simply inserting a space after the "function"
      keyword to match the current function toString behavior. When
      --harmony-function-tostring is enabled, the toString behavior matches
      the spacing used in the function declaration. With the declaration
      matching the current formatting, the toString behavior becomes
      unaffected by --harmony-function-tostring.
      
      BUG=v8:4958
      LOG=n
      
      Review-Url: https://codereview.chromium.org/2161413002
      Cr-Commit-Position: refs/heads/master@{#37959}
      3cfd80d6
  10. 20 Jul, 2016 1 commit
  11. 18 Jul, 2016 1 commit
    • jochen's avatar
      Reland^2 "Don't compile functions in a context the caller doesn't have access to" · 02ba2441
      jochen authored
      Original issue's description:
      > Don't compile functions in a context the caller doesn't have access to
      >
      > Instead just return undefined
      >
      > A side effect of this is that it's no longer possible to compile
      > functions in a detached context.
      >
      > BUG=chromium:541703
      > R=verwaest@chromium.org,bmeurer@chromium.org
      
      BUG=chromium:541703
      R=verwaest@chromium.org
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2155503004
      Cr-Commit-Position: refs/heads/master@{#37842}
      02ba2441
  12. 15 Jul, 2016 1 commit
  13. 14 Jul, 2016 4 commits
  14. 13 Jul, 2016 2 commits
    • bakkot's avatar
      Reland of Add errors for declarations which conflict with catch parameters.... · 819fe046
      bakkot authored
      Reland of Add errors for declarations which conflict with catch parameters. (patchset #1 id:1 of https://codereview.chromium.org/2112223002/ )
      
      Reason for revert:
      Correcting issue.
      
      Original issue's description:
      > Revert of Add errors for declarations which conflict with catch parameters. (patchset #6 id:100001 of https://codereview.chromium.org/2109733003/ )
      >
      > Reason for revert:
      > Fuzzer claims `try {  \"\" ; } catch(x) { let x1 = [1,,], x = x; }` causes a crash.
      >
      > Original issue's description:
      > > Add errors for declarations which conflict with catch parameters.
      > >
      > > Catch parameters are largely treated as lexical declarations in the
      > > block which contains their body for the purposes of early syntax errors,
      > > with some exceptions outlined in B.3.5. This patch introduces most of
      > > those errors, except those from `eval('for (var e of ...);')` inside of
      > > a catch with a simple parameter named 'e'.
      > >
      > > Note that annex B.3.5 allows var declarations to conflict with simple
      > > catch parameters, except when the variable declaration is the init of a
      > > for-of statement.
      > >
      > > BUG=v8:5112,v8:4231
      > >
      > > Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406
      > > Cr-Commit-Position: refs/heads/master@{#37462}
      >
      > TBR=littledan@chromium.org
      > # Skipping CQ checks because original CL landed less than 1 days ago.
      > NOPRESUBMIT=true
      > NOTREECHECKS=true
      > NOTRY=true
      > BUG=v8:5112,v8:4231
      >
      > Committed: https://crrev.com/8834d5ecb559001c87c42322969471da60574a8c
      > Cr-Commit-Position: refs/heads/master@{#37464}
      
      R=littledan@chromium.org
      BUG=v8:5112,v8:4231
      
      Review-Url: https://codereview.chromium.org/2119933002
      Cr-Commit-Position: refs/heads/master@{#37728}
      819fe046
    • mstarzinger's avatar
      [runtime] Fully remove RUNTIME_ASSERT for good. · 04062e92
      mstarzinger authored
      This fully deprecates all uses of the RUNTIME_ASSERT macro and removes
      the macro and underlying logging function in question. All uses have
      been replaces with CHECK macros which crash safely even in production.
      
      It makes sure we discover abuse of runtime functions in the wild early
      and also abort the process safely. Breaking assumptions in any runtime
      function can no longer accidentally be caught by JavaScript.
      
      R=yangguo@chromium.org
      BUG=v8:5066
      
      Review-Url: https://codereview.chromium.org/2132493002
      Cr-Commit-Position: refs/heads/master@{#37704}
      04062e92
  15. 12 Jul, 2016 1 commit
  16. 11 Jul, 2016 2 commits
  17. 07 Jul, 2016 1 commit
  18. 05 Jul, 2016 1 commit
  19. 02 Jul, 2016 1 commit
  20. 01 Jul, 2016 3 commits
    • littledan's avatar
      Implement immutable prototype chains · 0ff7b483
      littledan authored
      This patch implements "immutable prototype exotic objects" from the ECMAScript
      spec, which are objects whose __proto__ cannot be changed, but are not otherwise
      frozen. They are introduced in order to prevent a Proxy from being introduced
      to the prototype chain of the global object.
      
      The API is extended by a SetImmutablePrototype() call in ObjectTemplate, which
      can be used to vend new immutable prototype objects. Additionally, Object.prototype
      is an immutable prototype object.
      
      In the implementation, a new bit is added to Maps to say whether the prototype is
      immutable, which is read by SetPrototype. Map transitions to the immutable prototype
      state are not saved in the transition tree because the main use case is just for
      the prototype chain of the global object, which there will be only one of per
      Context, so no need to take up the extra word for a pointer in each full transition
      tree.
      
      BUG=v8:5149
      
      Review-Url: https://codereview.chromium.org/2108203002
      Cr-Commit-Position: refs/heads/master@{#37482}
      0ff7b483
    • bakkot's avatar
      Revert of Add errors for declarations which conflict with catch parameters.... · 8834d5ec
      bakkot authored
      Revert of Add errors for declarations which conflict with catch parameters. (patchset #6 id:100001 of https://codereview.chromium.org/2109733003/ )
      
      Reason for revert:
      Fuzzer claims `try {  \"\" ; } catch(x) { let x1 = [1,,], x = x; }` causes a crash.
      
      Original issue's description:
      > Add errors for declarations which conflict with catch parameters.
      >
      > Catch parameters are largely treated as lexical declarations in the
      > block which contains their body for the purposes of early syntax errors,
      > with some exceptions outlined in B.3.5. This patch introduces most of
      > those errors, except those from `eval('for (var e of ...);')` inside of
      > a catch with a simple parameter named 'e'.
      >
      > Note that annex B.3.5 allows var declarations to conflict with simple
      > catch parameters, except when the variable declaration is the init of a
      > for-of statement.
      >
      > BUG=v8:5112,v8:4231
      >
      > Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406
      > Cr-Commit-Position: refs/heads/master@{#37462}
      
      TBR=littledan@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5112,v8:4231
      
      Review-Url: https://codereview.chromium.org/2112223002
      Cr-Commit-Position: refs/heads/master@{#37464}
      8834d5ec
    • bakkot's avatar
      Add errors for declarations which conflict with catch parameters. · 2907c726
      bakkot authored
      Catch parameters are largely treated as lexical declarations in the
      block which contains their body for the purposes of early syntax errors,
      with some exceptions outlined in B.3.5. This patch introduces most of
      those errors, except those from `eval('for (var e of ...);')` inside of
      a catch with a simple parameter named 'e'.
      
      Note that annex B.3.5 allows var declarations to conflict with simple
      catch parameters, except when the variable declaration is the init of a
      for-of statement.
      
      BUG=v8:5112,v8:4231
      
      Review-Url: https://codereview.chromium.org/2109733003
      Cr-Commit-Position: refs/heads/master@{#37462}
      2907c726
  21. 29 Jun, 2016 2 commits
    • bakkot's avatar
      Amends the TypedArray constructor to use the path for primitives for all · f772c22c
      bakkot authored
      types of primitives, not just undefined, booleans, numbers, and strings.
      (The missing cases were null and Symbol.) This is required by the
      specification, and there are test262 tests which we were failing due to
      this bug.
      
      BUG=v8:5124
      
      Committed: https://crrev.com/f788bd9cce19815cba746e47bb65abfe25c16208
      Review-Url: https://codereview.chromium.org/2096873002
      Cr-Original-Commit-Position: refs/heads/master@{#37234}
      Cr-Commit-Position: refs/heads/master@{#37407}
      f772c22c
    • bakkot's avatar
      Sloppy-mode function declarations in blocks are now hoisted appropriately. · 9bbba144
      bakkot authored
      In ES2016, function declarations nested in blocks are formally allowed. This was
      never a part of ECMAScript, but was a common extension. Unfortunately
      implementations differed in the exact semantics. Annex B.3.3 in the spec tries
      to standardize the parts which are common to different implementations, but does
      so with some fairly complicated semantics.
      
      This CL addresses three issues related to annex B.3.3:
      * When the outer function had a complex parameter list, no hoisting whatsoever was
        being performed.
      * Hoisting was not blocked by parameters of the same name.
      * Hoisting was not blocked by nested lexical declarations of the same name.
      
      We had tests which checked for the second, but they were incorrectly passing due to
      the first. This CL adds more complete tests.
      
      BUG=v8:5151, v8:5111
      
      Review-Url: https://codereview.chromium.org/2099623003
      Cr-Commit-Position: refs/heads/master@{#37405}
      9bbba144
  22. 27 Jun, 2016 1 commit
    • franzih's avatar
      Fix toString() behavior on proxy objects. · 7e4c4cb5
      franzih authored
      Proxy objects need special treatment in toString(). Usually, we use the
      @@toStringTag, if it is set, otherwise we determine the result of toString()
      by checking IsArray() and other internal slots. According to
      ES2017 19.1.3.6, IsArray() and the internal slots  must be checked first,
      then get(@@toStringTag). The result of IsArray() and internal slots is discarded if
      @@toStringTag is set. For proxy
      objects, we must obey this order, because get() can have side-effects, i.e.,
      revoke the proxy. For all other objects, we can skip the check of the
      internal slots, if @@toStringTag is set.
      
      BUG=
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      
      Review-Url: https://codereview.chromium.org/2090773006
      Cr-Commit-Position: refs/heads/master@{#37289}
      7e4c4cb5
  23. 24 Jun, 2016 3 commits
  24. 23 Jun, 2016 2 commits
    • bakkot's avatar
      TypedArray.prototype.set uses internal length property, not real one. · 9f2a18b7
      bakkot authored
      TypedArrays store their true length in an internal slot. This is
      normally reflected in the .length property, but that property is
      configurable. Algorithms which need the length of a typed array are to
      use the internal slot, not the property; TypedArray.prototype.set was
      not doing this.
      
      BUG=v8:5133
      
      Review-Url: https://codereview.chromium.org/2091153002
      Cr-Commit-Position: refs/heads/master@{#37232}
      9f2a18b7
    • franzih's avatar
      Fix Object.prototype.toString() when @@toStringTag is not a string. · bdc78957
      franzih authored
      ES2017 draft 19.1.3.6: If @@toStringTag is not a string, Object.prototype.toString()
      returns [object Object], except in the following cases:
       - Array
       - String
       - Arguments
       - Function
       - Error
       - Boolean
       - Number
       - Date
       - RegExp.
      
      For anything else, e.g., Maps, Sets, TypedArrays, or the global object, toString() returns
      [object Object] if @@toStringTag is absent or not a string. In order to be able to
      easily identify the global object in d8, we set @@toStringTag to "global"
      for d8.
      
      CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
      BUG=
      
      Review-Url: https://codereview.chromium.org/2071343002
      Cr-Commit-Position: refs/heads/master@{#37218}
      bdc78957