Skip to content

V
V8
Switch branch/tag
  1. 05 Feb, 2016 24 commits
  3. 04 Feb, 2016 16 commits
    • adamk's avatar
      Support computed properties for ES2015 Function.name · 21c045a2
      adamk authored 
      Adds a new runtime function, %DefineDataPropertyInLiteral, which
takes a fifth argument specifying whether the property and value
are syntactically such that the value is a function (or class)
literal that should have its name set at runtime.

The new runtime call also allows us to eliminate the now-redundant
%DefineClassMethod runtime function.

This should get much less ugly once we can desugar the "dynamic"
part of object literals in the parser (but that work is currently
blocked on having a performant way of desugaring literals).

BUG=v8:3699, v8:3761
LOG=n

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

Cr-Commit-Position: refs/heads/master@{#33756}
      21c045a2
    • mbrandy's avatar
      PPC: Write barrier for storing a code entry, and usage in CompileLazy builtin. · ca255fd5
      mbrandy authored 
      Port 477e1336

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33755}
      ca255fd5
    • mbrandy's avatar
      PPC: [generators] Implement Generator.prototype.return. · bedb3344
      mbrandy authored 
      Port dbd86408

Original commit message:
    Note: This is currently only used by yield*, we still need to support it in
    other places (such as for-of loops).  It can be used manually of course.

    (This CL does not touch the full-codegen implementation of yield* because that
    code is already dead.  The yield* desugaring already supports return and doesn't
    need to be touched.)

R=neis@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:3566
LOG=y

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

Cr-Commit-Position: refs/heads/master@{#33754}
      bedb3344
    • mbrandy's avatar
      PPC: Type Feedback Vector lives in the closure · 753ad25e
      mbrandy authored 
      Port bb31db3a

Original commit message:
    (RELAND: the problem before was a missing write barrier for adding the code
    entry to the new closure. It's been addressed with a new macro instruction
    and test. The only change to this CL is the addition of two calls to
    __ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

    We get less "pollution" of type feedback if we have one vector per native
    context, rather than one for the whole system. This CL moves the vector
    appropriately.

    We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
    vector actually lives in the first slot of the literals array (indeed there is
    great commonality between those arrays, they can be thought of as the same
    thing). So we make greater effort to ensure there is a valid literals array
    after compilation.

    This meant, for performance reasons, that we needed to extend
    FastNewClosureStub to support creating closures with literals. And ultimately,
    it drove us to move the optimized code map lookup out of FastNewClosureStub
    and into the compile lazy builtin.

    The heap change is trivial so I TBR Hannes for it...
    Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
    And Benedikt reviewed it as well.

R=mvstanton@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33753}
      753ad25e
    • caitpotter88's avatar
      [esnext] implement Object.getOwnPropertyDescriptors() proposal · ee10b595
      caitpotter88 authored 
      BUG=v8:4725
LOG=N
R=adamk@chromium.org, cbruni@chromium.org, rossberg@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33752}
      ee10b595
    • alph's avatar
      Fix crash in SafeStackFrameIterator related to native frames entry/exit · 271f68ba
      alph authored 
      There might be several ExternalCallbackScope's created
during the native callback. Remove the assert that is not
aligned with that.

Moreover this iterator must work for any kind of
stacks including corrupted ones.

BUG=v8:4705
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33751}
      271f68ba
    • adamk's avatar
      Remove is_parenthesized bit from Expression and PreParserExpression · 1c318a9e
      adamk authored 
      This bit was ostensibly being used to provide appropriate syntax
errors for invalid destructuring assignment patterns, but adding a
single call to RecordPatternError() (in place of
BindingPatternUnexpectedToken()) seems to have replaced the need for it.

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

Cr-Commit-Position: refs/heads/master@{#33750}
      1c318a9e
    • adamk's avatar
      Remove unused 'needs_init' member of ParsingResult · 3d56b0d7
      adamk authored 
      Also various related cleanup in ParseVariableDeclarations(). The only
changes in logic are explained below:

  - We were redundantly checking for parenthesized binding patterns;
    these are already ruled out by BindingPatternUnexpectedToken()
    calls in the places where we hit an LPAREN.
  - There's no need to default-initialize a LET-mode variable in a
    for-each loop, just as there isn't for CONST or CONST_LEGACY
    (ParseForStatement will take care of properly initializing all
    of the above).

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

Cr-Commit-Position: refs/heads/master@{#33749}
      3d56b0d7
    • adamk's avatar
      Remove redundant/unnecessary variables and checks in ParseForStatement · ea8f7827
      adamk authored 
      Review URL: https://codereview.chromium.org/1663773003

Cr-Commit-Position: refs/heads/master@{#33748}
      ea8f7827
    • cbruni's avatar
      [proxies] allow duplicate keys for [[OwnPropertyKeys]] trap. · 07d05ddd
      cbruni authored 
      BUG=v8:4724, v8:1543
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33747}
      07d05ddd
    • oth's avatar
      [interpreter] Support for ES6 class literals. · 1b436ae1
      oth authored 
      Port of class literal support from the
ast-graph-builder implementation.

R=rmcilroy@chromium.org,mstarzinger@chromium.org
BUG=v8:4280,v8:4682
LOG=N

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

Cr-Commit-Position: refs/heads/master@{#33746}
      1b436ae1
    • mstarzinger's avatar
      [interpreter] Enable exception test that no longer fails. · d3ac2450
      mstarzinger authored 
      R=rmcilroy@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33745}
      d3ac2450
    • neis's avatar
      [generators] Implement Generator.prototype.return. · dbd86408
      neis authored 
      Note: This is currently only used by yield*, we still need to support it in
other places (such as for-of loops).  It can be used manually of course.

(This CL does not touch the full-codegen implementation of yield* because that
code is already dead.  The yield* desugaring already supports return and doesn't
need to be touched.)

BUG=v8:3566
LOG=y

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

Cr-Commit-Position: refs/heads/master@{#33744}
      dbd86408
    • neis's avatar
      Fix embarrassing bug in last-minute change to yield* CL. · 813f48ff
      neis authored 
      R=littledan@chromium.org
BUG=

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

Cr-Commit-Position: refs/heads/master@{#33743}
      813f48ff
    • jfb's avatar
      WebAssembly: add stack trace test · ad6b8542
      jfb authored 
      The test currently only shows the JavaScript stack frames, I'll then add
support for interleaved WebAssembly stack frames and update the test.

R=titzer@chromium.org

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

Cr-Commit-Position: refs/heads/master@{#33742}
      ad6b8542
    • mvstanton's avatar
      Type Feedback Vector lives in the closure · bb31db3a
      mvstanton authored 
      (RELAND: the problem before was a missing write barrier for adding the code
entry to the new closure. It's been addressed with a new macro instruction
and test. The only change to this CL is the addition of two calls to
__ RecordWriteCodeEntryField() in the platform CompileLazy builtin.)

We get less "pollution" of type feedback if we have one vector per native
context, rather than one for the whole system. This CL moves the vector
appropriately.

We rely more heavily on the Optimized Code Map in the SharedFunctionInfo. The
vector actually lives in the first slot of the literals array (indeed there is
great commonality between those arrays, they can be thought of as the same
thing). So we make greater effort to ensure there is a valid literals array
after compilation.

This meant, for performance reasons, that we needed to extend
FastNewClosureStub to support creating closures with literals. And ultimately,
it drove us to move the optimized code map lookup out of FastNewClosureStub
and into the compile lazy builtin.

The heap change is trivial so I TBR Hannes for it...
Also, Yang has had a look at the debugger changes already and approved 'em. So he is TBR style too.
And Benedikt reviewed it as well.

TBR=hpayer@chromium.org, yangguo@chromium.org, bmeurer@chromium.org

BUG=

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

Cr-Commit-Position: refs/heads/master@{#33741}
      bb31db3a