Use the Call builtin instead, which does the right thing(TM)
always, especially since the CallFunctionStub is going away.
R=jarin@chromium.org
BUG=v8:4413
LOG=n
Review URL: https://codereview.chromium.org/1410853007
Cr-Commit-Position: refs/heads/master@{#31794}
This removes several methods from JSFunction that just delegate to
SharedFunctionInfo. These methods are especially dangerous when they
hide the fact that they potentially affect all function instances
deriving from the same underlying SharedFunctionInfo.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1417213005
Cr-Commit-Position: refs/heads/master@{#31792}
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
LOG=N
BUG=v8:4428
Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
Cr-Commit-Position: refs/heads/master@{#31786}
Review URL: https://codereview.chromium.org/1418623007
Cr-Commit-Position: refs/heads/master@{#31790}
The callees are expected to properly set the number of actual
arguments passed to the callee, which is now represented correctly
in the TurboFan graphs by a new Parameter right before the context
Parameter. Currently this is only being used for outgoing calls.
Note that this requires disabling two of the TF code stub tests,
because of the JavaScript graphs are not automagically compatible
with abitrary (incoming) code stub interface descriptors. If we
want to support JS code stubs at all, then we need to find a sane
way to feed in this information.
Drive-by-fix: Don't insert a direct call to a classConstructor.
R=mstarzinger@chromium.org
BUG=v8:4413, v8:4428
LOG=n
Review URL: https://codereview.chromium.org/1410633006
Cr-Commit-Position: refs/heads/master@{#31789}
Reason for revert:
failing build bot
Original issue's description:
> [runtime] Fix ES6 9.2.1 [[Call]] when encountering a classConstructor.
>
> The current implementation of classes throws the TypeError at the wrong
> point, after activating a new context when directly calling a class
> constructor. According to the spec, the TypeError has to be thrown
> in the caller context.
>
> LOG=N
> BUG=v8:4428
>
> Committed: https://crrev.com/6a06bc0a774933719f62009d81b3f1686d83bb90
> Cr-Commit-Position: refs/heads/master@{#31786}
TBR=bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4428
Review URL: https://codereview.chromium.org/1415783006
Cr-Commit-Position: refs/heads/master@{#31787}
The current implementation of classes throws the TypeError at the wrong
point, after activating a new context when directly calling a class
constructor. According to the spec, the TypeError has to be thrown
in the caller context.
LOG=N
BUG=v8:4428
Review URL: https://codereview.chromium.org/1418623007
Cr-Commit-Position: refs/heads/master@{#31786}
Call directly into the ArgumentsAdaptorTrampoline when we call a known
JSFunction, but that actual argument count doesn't match the expected
argument count.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1417213004
Cr-Commit-Position: refs/heads/master@{#31781}
This makes the description in the README file for our test262 harness
independent of the underlying revision. The one canonical place to
mention the up-to-date revision is the DEPS file.
R=machenbach@chromium.org
NOTRY=true
Review URL: https://codereview.chromium.org/1424043006
Cr-Commit-Position: refs/heads/master@{#31778}
This removes special casing for the 'f.arguments' property accessor. Any
local 'arguments' variable should not be allowed to influence the value
returned by the indirect 'f.arguments' property. That property creates a
new object with a separate identity everytime it is read. This is by now
consistent with other browsers.
R=rossberg@chromium.org
TEST=mjsunit/arguments-indirect
Review URL: https://codereview.chromium.org/1408983006
Cr-Commit-Position: refs/heads/master@{#31776}
Adds support for calling JS runtime functions. Also changes the bytecode
array builder to allow calling functions with an invalid argument
register if the call takes no arguments.
Adds the bytecode CallJSRuntime.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1410003003
Cr-Commit-Position: refs/heads/master@{#31774}
Use the type specified for StoreField and StoreElement to check whether
we are storing a TaggedSigned value, and skip the write barrier for the
write completely in that case. Also make sure to set that field type
appropriately for JSGlobalObjectSpecialization.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1410743009
Cr-Commit-Position: refs/heads/master@{#31772}
We don't need to distinguish between signed and unsigned integral
representations in the big boy type system. It actually even hurts
in some cases. The representation is only about the way the values
are mapped to bits in memory/registers, but the interpretation of
the bits is specified by the semantic dimension.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1416953006
Cr-Commit-Position: refs/heads/master@{#31771}
We used to mark a block as needing frame based solely on
the spill list. With splintering, that is not entirely
accurate. With this change, for ranges that spill only in
deferred blocks, we mark the start of each block in which a
child range spills as needing a frame.
BUG=v8:4533
LOG=n
Review URL: https://codereview.chromium.org/1408183007
Cr-Commit-Position: refs/heads/master@{#31769}
The "harmony"-prefixed files have been included in the snapshot for
several releases now, and were only separate originally to enable
loading them via a runtime flag. This patch simply merges them into
the main implementation files for Arrays and TypedArrays, respectively.
Review URL: https://codereview.chromium.org/1416243007
Cr-Commit-Position: refs/heads/master@{#31767}
Corrects LdaGlobal to deal with TypeofMode::INSIDE_TYPEOF so that it
doesn't throw a reference error on undefined globals.
BUG=v8:4280
LOG=N
Review URL: https://codereview.chromium.org/1422443006
Cr-Commit-Position: refs/heads/master@{#31757}
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 matches the approach used for @@isConcatSpreadable, and seems to
match what Mozilla is planning to do in Firefox.
Given that there's already little compatibility around cross-origin toString
results, there seems to be little hazard in making this change even before
spec language hits the HTML spec.
BUG=v8:3502, v8:4289, chromium:532469
LOG=n
Review URL: https://codereview.chromium.org/1432543002
Cr-Commit-Position: refs/heads/master@{#31755}
If the property is a data property on the holder (or does not exist) and is a readonly data property in the receiver, then we must fail.
R=rossberg, verwaest@chromium.org
BUG=
Review URL: https://codereview.chromium.org/1424233005
Cr-Commit-Position: refs/heads/master@{#31751}
The JSNativeContextSpecialization class is getting rather huge with all
the stuff related to property and element access going in. Splitting off
the global object related stuff into JSGlobalObjectSpecialization seems
like a natural separation, especially since the global object
specialization is sort of separate issue anyway. This is neutral
functionality- and performance-wise.
R=jarin@chromium.org
BUG=v8:4470
LOG=n
Review URL: https://codereview.chromium.org/1417043006
Cr-Commit-Position: refs/heads/master@{#31748}
