1. Location names with more than one underscores (e.g. Ho_Chi_Minh)
didn't work because of the way capturing works with repeated patterns
in RE. It's now supported by changing the RE to capture the whole string
and splitting on '_' in the next step.
2. Adds support for location names with a hyphen
3. Adds support for timezone ids with three parts (e.g.
American/Argentina/Buenos_Aires)
4. Adds special handling of 'au', 'es' and 'of' in zone ids. They need to be kept in lowercase. (see the full list at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones )
5. Adds regression tests for all the above and make the existing tests
more robust against future ICU changes. ICU canonicalizes zone names to
deprecated names, but it may change. (
http://bugs.icu-project.org/trac/ticket/12044 )
BUG=364374
LOG=Y
Review URL: https://codereview.chromium.org/1529363005
Cr-Commit-Position: refs/heads/master@{#33097}
In addition to ThrowTypeError not being a constructor, it was invalidly set up by simply swapping the map. Swapping the map is insufficient since NewFunction* actually set up the function depending on the used map.
BUG=chromium:573858
LOG=n
Review URL: https://codereview.chromium.org/1552223002
Cr-Commit-Position: refs/heads/master@{#33082}
The Object.freeze, Object.isExtensible, Object.isFrozen,
Object.isSealed, Object.preventExtensions and Object.seal builtins were
already implemented in C++, but they still had some funny JavaScript
wrappers that just called into the C++ implementation on every
(interesting) execution path.
Review URL: https://codereview.chromium.org/1553043002
Cr-Commit-Position: refs/heads/master@{#33074}
Unify the constructors and isView methods for ArrayBuffer and
SharedArrayBuffer, moving them to C++ because there's no point
in having the JavaScript wrappers for them.
We choose to deliberately violate the ES2015 specification and
implement the ArrayBuffer constructor in a way that matches
Firefox and Safari instead.
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
BUG=chromium:565917, v8:4592
TBR=hpayer@chromium.orgR=cbruni@chromium.org
LOG=n
Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e
Cr-Commit-Position: refs/heads/master@{#32590}
Review URL: https://codereview.chromium.org/1500543002
Cr-Commit-Position: refs/heads/master@{#33072}
In a rare edge case, a difference in checks between C++ and
JavaScript lead to an 'illegal access' being thrown by the Date
constructor. This patch harmonizes the checks from both sides.
It's possible that slightly larger dates could be permitted,
as the ECMAScript 2015 specification indicates that +287396-10-12
would be a permissible date in the note in
http://tc39.github.io/ecma262/#sec-extended-years
This patch does not revisit the limit, only clears up the
inconsistency.
BUG=v8:4640
R=cbruni
LOG=Y
Review URL: https://codereview.chromium.org/1545883003
Cr-Commit-Position: refs/heads/master@{#33068}
Reason for revert:
Should be fixed again with this Blink change to add NeedsManualRebaseline
Original issue's description:
> Revert of Use ES2015-style TypedArray prototype chain (patchset #5 id:80001 of https://codereview.chromium.org/1541233002/ )
>
> Reason for revert:
> [Sheriff] Changes layout tests. Please fix upstream first if intended.
>
> https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689
>
> Original issue's description:
> > Use ES2015-style TypedArray prototype chain
> >
> > This patch switches TypedArrays to use the prototype chain described
> > in the ES2015 specification, which adds a %TypedArray% superclass above
> > all individual TypedArray types. Most methods are defined on the
> > superclass rather than the subclasses.
> >
> > In order to prevent a performance regression, a few methods are
> > marked as inline. Inlining might prevent code which was previously
> > monomorphic from becoming polymorphic, and it was specifically
> > applied in places where methods became more polymorphic than before.
> > Tests with realistic workloads would be nice to do before this
> > ships in stable.
> >
> > This patch does not bring TypedArrays up to full spec compliance. In
> > particular, @@species is not yet supported.
> >
> > R=cbruni
> > BUG=v8:4085
> > LOG=Y
> >
> > Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7
> > Cr-Commit-Position: refs/heads/master@{#33050}
>
> TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=v8:4085
>
> Committed: https://crrev.com/28b55ffd1e32e09aaf42b8bbb407944d4808e07c
> Cr-Commit-Position: refs/heads/master@{#33053}
TBR=caitpotter88@gmail.com,cbruni@chromium.org,machenbach@chromium.org
BUG=v8:4085
LOG=Y
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1558663002
Cr-Commit-Position: refs/heads/master@{#33067}
This patch relands a change to ES2015 Promises which brings us closer to
spec compliance. In this new version, a bug which would lose async callstack
data was fixed.
R=adamk
CC=rossberg,caitp
LOG=Y
BUG=v8:3641
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1538663002
Cr-Commit-Position: refs/heads/master@{#33065}
This matches the behavior of JSObject::JSObjectVerify() and seems to be
the current contract for --verify-heap.
BUG=chromium:572590
LOG=n
Review URL: https://codereview.chromium.org/1553463002
Cr-Commit-Position: refs/heads/master@{#33056}
Reason for revert:
[Sheriff] Changes layout tests. Please fix upstream first if intended.
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3689
Original issue's description:
> Use ES2015-style TypedArray prototype chain
>
> This patch switches TypedArrays to use the prototype chain described
> in the ES2015 specification, which adds a %TypedArray% superclass above
> all individual TypedArray types. Most methods are defined on the
> superclass rather than the subclasses.
>
> In order to prevent a performance regression, a few methods are
> marked as inline. Inlining might prevent code which was previously
> monomorphic from becoming polymorphic, and it was specifically
> applied in places where methods became more polymorphic than before.
> Tests with realistic workloads would be nice to do before this
> ships in stable.
>
> This patch does not bring TypedArrays up to full spec compliance. In
> particular, @@species is not yet supported.
>
> R=cbruni
> BUG=v8:4085
> LOG=Y
>
> Committed: https://crrev.com/07c91dccbe55c7be3ec75857dee5ad59873330b7
> Cr-Commit-Position: refs/heads/master@{#33050}
TBR=caitpotter88@gmail.com,cbruni@chromium.org,littledan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4085
Review URL: https://codereview.chromium.org/1554523002
Cr-Commit-Position: refs/heads/master@{#33053}
This patch switches TypedArrays to use the prototype chain described
in the ES2015 specification, which adds a %TypedArray% superclass above
all individual TypedArray types. Most methods are defined on the
superclass rather than the subclasses.
In order to prevent a performance regression, a few methods are
marked as inline. Inlining might prevent code which was previously
monomorphic from becoming polymorphic, and it was specifically
applied in places where methods became more polymorphic than before.
Tests with realistic workloads would be nice to do before this
ships in stable.
This patch does not bring TypedArrays up to full spec compliance. In
particular, @@species is not yet supported.
R=cbruni
BUG=v8:4085
LOG=Y
Review URL: https://codereview.chromium.org/1541233002
Cr-Commit-Position: refs/heads/master@{#33050}
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.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
Cr-Commit-Position: refs/heads/master@{#33042}
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33044}
Reason for revert:
Breaks arm64 sim nosnap: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20nosnap%20-%20debug/builds/805/steps/Check/logs/function-bind
Original issue's description:
> [runtime] Introduce dedicated JSBoundFunction to represent bound functions.
>
> 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.
>
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
> BUG=chromium:535408, chromium:571299, v8:4629
> LOG=n
>
> Committed: https://crrev.com/ca8623eaa468cba65a5adafcdfb4615966f43ce2
> Cr-Commit-Position: refs/heads/master@{#33042}
TBR=cbruni@chromium.org,hpayer@chromium.org,yangguo@chromium.org,akos.palfi@imgtec.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:535408, chromium:571299, v8:4629
Review URL: https://codereview.chromium.org/1552473002
Cr-Commit-Position: refs/heads/master@{#33043}
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.
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
BUG=chromium:535408, chromium:571299, v8:4629
LOG=n
Review URL: https://codereview.chromium.org/1542963002
Cr-Commit-Position: refs/heads/master@{#33042}
These constructors always go through C++ at least twice anyway, so
there's not really a point in trying to implement them in JavaScript.
R=yangguo@chromium.org
BUG=chromium:535408
LOG=n
Review URL: https://codereview.chromium.org/1548623002
Cr-Commit-Position: refs/heads/master@{#33012}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
Cr-Commit-Position: refs/heads/master@{#32841}
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32857}
We used to flood the handler when preparing for stepping,
even if we may not throw. Instead, we now flood the
handler only when we actually throw.
This also solves an issue with step-next when we throw and
leave the function unexpectedly. In combination with
microtasks, this could cause a crash.
R=mstarzinger@chromium.org
BUG=chromium:568477
LOG=N
Review URL: https://codereview.chromium.org/1527593002
Cr-Commit-Position: refs/heads/master@{#32856}
Reason for revert:
[Sheriff] Layout test changes.
Original issue's description:
> [debugger] debug-evaluate should not not modify local values.
>
> Debug evaluate no longer writes back changes to the replicated
> context chain to the original after execution. Changes to the
> global object or script contexts still stick. Calling functions
> that bind to the original context chain also have their expected
> side effects.
>
> As far as I can tell, DevTools is not interested in modifying
> local variable values. Modifying global variable values still
> works as expected. However, I have not yet removed the old
> implementation, but merely keep it behind a flag.
>
> R=mstarzinger@chromium.org, rossberg@chromium.org
>
> Committed: https://crrev.com/92caa9b85eefffbef51c67428397951bd2e2c330
> Cr-Commit-Position: refs/heads/master@{#32841}
TBR=mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1526553003
Cr-Commit-Position: refs/heads/master@{#32845}
Debug evaluate no longer writes back changes to the replicated
context chain to the original after execution. Changes to the
global object or script contexts still stick. Calling functions
that bind to the original context chain also have their expected
side effects.
As far as I can tell, DevTools is not interested in modifying
local variable values. Modifying global variable values still
works as expected. However, I have not yet removed the old
implementation, but merely keep it behind a flag.
R=mstarzinger@chromium.org, rossberg@chromium.org
Review URL: https://codereview.chromium.org/1513183003
Cr-Commit-Position: refs/heads/master@{#32841}
There's at least one case of a time zone alias: Asia/Kathmandu aliases
Asia/Katmandu. ICU seems to normalize to the (deprecated) latter choice.
V8 internationalization choked on this change; this patch interprets
ICU's output more precisely and allows it.
BUG=chromium:487322
R=jungshik,adamk
LOG=Y
Review URL: https://codereview.chromium.org/1509273007
Cr-Commit-Position: refs/heads/master@{#32769}
Without this fix, AssignmentExpressions that happen to be arrow functions
would lead to unbalanced Enter/Leave calls on the fni_, causing thrashing
while trying to infer function names. Symptoms include slow parsing
or OOM (when we create too many AstConsStrings).
To try to keep this from happening in the future, added an RAII helper
class to handle Entering/Leaving FNI state.
The included regression test crashes on my workstation without the patch.
Note that it's too slow in debug mode (as well as under TurboFan),
so I've skipped it there.
BUG=v8:4595
LOG=y
Review URL: https://codereview.chromium.org/1507283003
Cr-Commit-Position: refs/heads/master@{#32768}
This is in preparation for turning the flag off by default.
BUG=chromium:552100
LOG=n
Review URL: https://codereview.chromium.org/1511293002
Cr-Commit-Position: refs/heads/master@{#32729}
- Add JSReceiver::SetIntegrityLevel, with a fast path for regular objects.
- Make Object.{freeze,seal} call this via %Object{Freeze,Seal}, thus no longer
using broken or deprecated functions from v8natives.js.
- Add JSReceiver::OwnPropertyKeys convenience function.
- Reenable harmony/proxies-hash.js test.
R=rossberg
BUG=v8:1543
LOG=N
Review URL: https://codereview.chromium.org/1489423002
Cr-Commit-Position: refs/heads/master@{#32651}
The backing store is only held alive indirectly via the array buffer
referenced by the holder (typed array), so it's not enough to keep the
elements alive (or even just the external pointer loaded from the
elements).
R=mstarzinger@chromium.org,bmeurer@chromium.org
LOG=n
BUG=v8:1827
Review URL: https://codereview.chromium.org/1493983004
Cr-Commit-Position: refs/heads/master@{#32644}
Reason for revert:
[Sheriff] Breaks layout tests:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/3266
Please request rebase upstream first.
Original issue's description:
> Clean up promises and fix an edge case bug
>
> This patch builds on previous Promise spec compliance work by
> cleaning out some old code which existed to support
> Promise.prototype.chain, rephrasing some code to correspond more
> closely to the specification, and removing some incorrect brand
> checking. A test is added for a bug in an edge case which was fixed.
>
> R=rossberg
> BUG=v8:3641
> LOG=Y
>
> Committed: https://crrev.com/1deb89c8fd3cb69714ae0a24e3b5a4e78f6b73b4
> Cr-Commit-Position: refs/heads/master@{#32627}
TBR=rossberg@chromium.org,caitpotter88@gmail.com,littledan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:3641
Review URL: https://codereview.chromium.org/1501763004
Cr-Commit-Position: refs/heads/master@{#32629}
This patch builds on previous Promise spec compliance work by
cleaning out some old code which existed to support
Promise.prototype.chain, rephrasing some code to correspond more
closely to the specification, and removing some incorrect brand
checking. A test is added for a bug in an edge case which was fixed.
R=rossberg
BUG=v8:3641
LOG=Y
Review URL: https://codereview.chromium.org/1488783002
Cr-Commit-Position: refs/heads/master@{#32627}
Reason for revert:
Blocks the roll:
https://codereview.chromium.org/1497763004/
Original issue's description:
> [es6] Correctify and unify ArrayBuffer and SharedArrayBuffer constructors.
>
> The ArrayBuffer and SharedArrayBuffer constructors should raise an
> exception when called with no arguments or undefined length. Also
> unified the ArrayBuffer and SharedArrayBuffer implementations as C++
> builtins, and removed some (now) obsolete runtime entries.
>
> R=yangguo@chromium.org
>
> Committed: https://crrev.com/3235ccbb7826ceec2188f6ebab98fc851b54f60e
> Cr-Commit-Position: refs/heads/master@{#32590}
TBR=yangguo@chromium.org,cbruni@chromium.org,adamk@chromium.org,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1501673002
Cr-Commit-Position: refs/heads/master@{#32606}
The ArrayBuffer and SharedArrayBuffer constructors should raise an
exception when called with no arguments or undefined length. Also
unified the ArrayBuffer and SharedArrayBuffer implementations as C++
builtins, and removed some (now) obsolete runtime entries.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/1500543002
Cr-Commit-Position: refs/heads/master@{#32590}
non-constructors are not allowed to have initial maps. The optimizing compilers used to add initial maps unconditionally to functions used as right-hand-side in instanceof.
BUG=
Review URL: https://codereview.chromium.org/1490003003
Cr-Commit-Position: refs/heads/master@{#32497}
This fixes a corner-case in redeclaration handling, where the ES2015
early error case got mixed up with legacy const handling in the parser.
Redeclaration using ES2015 'let' and 'const' should be early errors,
but legacy 'const' redeclaration has historically been a runtime error,
and should stay that way until legacy 'const' is gone.
The fix here is uglier than it might be due to
https://code.google.com/p/v8/issues/detail?id=4577, which keeps us
from simplifying the mess of if/else-if in the current code.
BUG=v8:4576
LOG=n
Review URL: https://codereview.chromium.org/1485943002
Cr-Commit-Position: refs/heads/master@{#32429}
This replaces internal GetConstructorName with toStringTag, .constructor's name
and class_name. This entirely changes how the name is computed for use in
devtools.
BUG=chromium:529177
LOG=n
Review URL: https://codereview.chromium.org/1435273002
Cr-Commit-Position: refs/heads/master@{#32374}
We currently assume that all prototype maps are stable, which is
not guaranteed for certain keyed access patterns. So we explicitly
disallow optimizing the element access there for now.
BUG=chromium:557807, v8:4470
R=jarin@chromium.org
LOG=n
Review URL: https://codereview.chromium.org/1456973004
Cr-Commit-Position: refs/heads/master@{#32101}
This is in preparation for the addition of --harmony-destructuring-assignment.
BUG=v8:811
LOG=n
Review URL: https://codereview.chromium.org/1450193002
Cr-Commit-Position: refs/heads/master@{#32098}
When adding properties to the result object, that object's prototype chain should be ignored.
Review URL: https://codereview.chromium.org/1458873002
Cr-Commit-Position: refs/heads/master@{#32085}
This fixes the array literal expression stack tracking in the presence
of spread expressions. Deoptimization within a spread expression was
borked.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-deopt-in-array-literal-spread
Review URL: https://codereview.chromium.org/1455953002
Cr-Commit-Position: refs/heads/master@{#32079}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1453733002
Cr-Commit-Position: refs/heads/master@{#32050}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1452193003
Cr-Commit-Position: refs/heads/master@{#32048}
With do-expressions any expression used within literals can turn into an
OSR entry-point. This means the literal object being constructed is then
renamed to an OSR value and needs to be reloaded from the environment.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-literal
Review URL: https://codereview.chromium.org/1451423002
Cr-Commit-Position: refs/heads/master@{#32047}
With do-expressions any expression used as a case label can turn into an
OSR entry-point. This means the value being switched over is renamed to
an OSR value and needs to be reloaded from the environment at each case.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-osr-in-case-label
Review URL: https://codereview.chromium.org/1438123007
Cr-Commit-Position: refs/heads/master@{#31986}
This makes sure that inlining a constructor call to a function which
cannot be used as a constructor (e.g. strong mode function) still does
throw correctly when the implicit receiver is created.
R=bmeurer@chromium.org
TEST=mjsunit/regress/regress-inline-strong-as-construct
BUG=v8:4544
LOG=n
Review URL: https://codereview.chromium.org/1447443002
Cr-Commit-Position: refs/heads/master@{#31982}
JSRegExp's properties backing stores must not be shared.
BUG=chromium:548580
LOG=N
Review URL: https://codereview.chromium.org/1429743006
Cr-Commit-Position: refs/heads/master@{#31867}
We forgot to add the number of arguments parameter in
JSFrameSpecialization, which was added before the context.
R=jarin@chromium.org
BUG=chromium:552304
LOG=n
Review URL: https://codereview.chromium.org/1429233004
Cr-Commit-Position: refs/heads/master@{#31856}
This fixes receiver conversion since the Call builtin does it correctly.
BUG=v8:4526
LOG=n
Review URL: https://codereview.chromium.org/1407373007
Cr-Commit-Position: refs/heads/master@{#31823}
The %_CallFunction doesn't implement the call sequence properly, it
doesn't do the receiver wrapping, nor does it check for
classConstructor. Also the eager deoptimization for %_CallFunction was
seriously b0rked (we must have been lucky with TurboFan so far).
R=yangguo@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1419813010
Cr-Commit-Position: refs/heads/master@{#31821}
Original issue's description:
> [es6] Fix Function and GeneratorFunction built-ins subclassing.
>
> BUG=v8:3101, v8:3330
> LOG=Y
>
> Committed: https://crrev.com/99e7f872d3d0a5fb799dcbafb05537cda491314a
> Cr-Commit-Position: refs/heads/master@{#31708}
The problem was in another CL, this is a clean reland with improved tests.
BUG=v8:3101, v8:3330
LOG=Y
Review URL: https://codereview.chromium.org/1415683007
Cr-Commit-Position: refs/heads/master@{#31756}
This fixes [NAMED|KEYED]_SUPER_PROPERTY_CALL to perform a method call
instead of a function call. The difference is visible for sloppy mode
targets that convert primitive receivers.
R=rossberg@chromium.org
TEST=mjsunit/regress/regress-4525
BUG=v8:4525
LOG=n
Review URL: https://codereview.chromium.org/1419173004
Cr-Commit-Position: refs/heads/master@{#31664}
