Skip to content

V
V8
Switch branch/tag
  1. 26 Jan, 2016 1 commit
  3. 25 Jan, 2016 2 commits
  5. 23 Jan, 2016 1 commit
  7. 22 Jan, 2016 1 commit
    • ishell's avatar
      Array length reduction should throw in strict mode if it can't delete an element. · ed2be747
      ishell authored 
      When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.

Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.

This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.

BUG=v8:4267
LOG=Y

Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
Cr-Commit-Position: refs/heads/master@{#33438}

Review URL: https://codereview.chromium.org/1587073003

Cr-Commit-Position: refs/heads/master@{#33461}
      ed2be747
  9. 21 Jan, 2016 3 commits
    • machenbach's avatar
      Revert of Array length reduction should throw in strict mode if it can't... · 575e90c1
      machenbach authored 
      Revert of Array length reduction should throw in strict mode if it can't delete an element. (patchset #7 id:220001 of https://codereview.chromium.org/1587073003/ )

Reason for revert:
[Sheriff] Breaks layout tests. Please fix upstream.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/4077

Original issue's description:
> Array length reduction should throw in strict mode if it can't delete an element.
>
> When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.
>
> Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.
>
> This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.
>
> BUG=v8:4267
> LOG=Y
>
> Committed: https://crrev.com/1d3e837fcbbd9d9fd5e72dfe85dfd47c025f3c9f
> Cr-Commit-Position: refs/heads/master@{#33438}

TBR=verwaest@chromium.org,ishell@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4267

Review URL: https://codereview.chromium.org/1611313003

Cr-Commit-Position: refs/heads/master@{#33444}
      575e90c1
    • ishell's avatar
      Array length reduction should throw in strict mode if it can't delete an element. · 1d3e837f
      ishell authored 
      When accessor getter callback is called the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, since according to ES6 there's no difference between strict and non-strict property loads. For the setter case the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true if the property is set in strict context.

Interceptors follow same idea: for getter, enumerator and query callbacks the v8::PropertyCallbackInfo::ShouldThrowOnError() is always false, and for setter and deleter callback the v8::PropertyCallbackInfo::ShouldThrowOnError() returns true in strict context.

This CL also cleans up the CallApiGetterStub and removes bogus asserts from [arm] Push(reg1, reg2, ..., regN) that prevented from pushing a set of registers containing duplicates.

BUG=v8:4267
LOG=Y

Review URL: https://codereview.chromium.org/1587073003

Cr-Commit-Position: refs/heads/master@{#33438}
      1d3e837f
    • zhengxing.li's avatar
      X87: [interpreter] First implementation of stack unwinding. · 02e7906e
      zhengxing.li authored 
        port 0b3066b8 (r33414)

  original commit message:
  This implements a first prototype of stack unwinding for interpreted
  frames. The unwinding machinery performs a range-based lookup in the
  given handler table and potentially continues dispatching at the handler
  offset. Note that this does not yet correctly restore the context to the
  correct value when the handler is being entered.

BUG=

Review URL: https://codereview.chromium.org/1616613002

Cr-Commit-Position: refs/heads/master@{#33425}
      02e7906e
  11. 20 Jan, 2016 1 commit
  13. 18 Jan, 2016 3 commits
  15. 15 Jan, 2016 2 commits
    • cbruni's avatar
      [runtime] Throw exception for derived constructors in correct context. · c86f1897
      cbruni authored 
      When derived constructors return a non-object (or not undefined) we
currently throw an exception directly in the callee context. This was
achieved by desugaring the return statement for derived classes. To
be spec compliamnt a separate ConstructStubForDerived is introduced.
Instead of trowing directly, the desugared return statement inside
a derived constructor only returns an integer to indicate an incompatible
result.

BUG=v8:4509
LOG=n

Review URL: https://codereview.chromium.org/1593553002

Cr-Commit-Position: refs/heads/master@{#33336}
      c86f1897
    • mstarzinger's avatar
      Move SourcePosition into separate header file. · 0aeaf0cb
      mstarzinger authored 
      This splits out the SourcePosition class into a separate header file.
Reason for this refactoring is that said class is mostly used by the
Crankshaft compiler and not needed for all compilers. Also having the
assembler depend on the class creates a dependency cycle.

R=bmeurer@chromium.org

Review URL: https://codereview.chromium.org/1581083009

Cr-Commit-Position: refs/heads/master@{#33325}
      0aeaf0cb
  17. 14 Jan, 2016 3 commits
  19. 12 Jan, 2016 1 commit
  21. 11 Jan, 2016 2 commits
  23. 07 Jan, 2016 1 commit
  25. 05 Jan, 2016 2 commits
  27. 31 Dec, 2015 1 commit
  29. 30 Dec, 2015 1 commit
  31. 29 Dec, 2015 1 commit
  33. 28 Dec, 2015 2 commits
    • bmeurer's avatar
      [builtins] Fix context for ConstructStub calls into C++. · cf25c241
      bmeurer authored 
      When calling into C++ for a ConstructStub, we need to enter the target
context manually currently, which seems to be too fragile and easy to
forget. So instead of doing that manually, we just always enter the
correct context in the trampoline.

Drive-by-fix: Trivial cleanups for some builtins.

R=cbruni@chromium.org

Review URL: https://codereview.chromium.org/1551473002

Cr-Commit-Position: refs/heads/master@{#33051}
      cf25c241
    • zhengxing.li's avatar
      X87: [runtime] Introduce dedicated JSBoundFunction to represent bound functions. · 37d1dd82
      zhengxing.li authored 
        port 97def807 (r33044)

  original commit message:
  According to the ES2015 specification, bound functions are exotic
  objects, and thus don't need to be implemented as JSFunctions. So
  we introduce a new JSBoundFunction type to represent bound functions
  and make them optimizable. This already improves the performance of
  calling or constructing bound functions by 10-100x depending on the
  use case because we avoid the crazy dance between JavaScript and C++
  that was implemented in v8natives.js previously.

  There's still room for improvement in the performance of actually
  creating bound functions, which is also relevant in practice, but
  we already have a plan how to accomplish that later.

  The mips/mips64 ports were contributed by akos.palfi@imgtec.com.

BUG=

Review URL: https://codereview.chromium.org/1548253002

Cr-Commit-Position: refs/heads/master@{#33046}
      37d1dd82
  35. 24 Dec, 2015 2 commits
  37. 23 Dec, 2015 2 commits
  39. 21 Dec, 2015 1 commit
  41. 18 Dec, 2015 1 commit
    • zhengxing.li's avatar
      X87: [es6] Correct Function.prototype.apply, Reflect.construct and Reflect.apply. · bea8d4c9
      zhengxing.li authored 
        port 5bd48324 (r32929)

  original commit message:
  Introduce a new Apply builtin that forms a correct and optimizable foundation for the Function.prototype.apply, Reflect.construct and Reflect.apply builtins
  (which properly does the PrepareForTailCall as required by the ES2015 spec). The new Apply builtin avoids going to the runtime if it is safe to just access
  the backing store elements of the argArray, i.e. if you pass a JSArray with no holes, or an unmapped, unmodified sloppy or strict arguments object.

  mips/mips64 ports by Balazs Kilvady <balazs.kilvady@imgtec.com>;

BUG=

Review URL: https://codereview.chromium.org/1534543003

Cr-Commit-Position: refs/heads/master@{#32960}
      bea8d4c9
  43. 17 Dec, 2015 2 commits
  45. 16 Dec, 2015 1 commit
  47. 11 Dec, 2015 2 commits
  49. 10 Dec, 2015 1 commit