The spec says ToObject is called on the receiver, and this is
observable if you call sort on a primitive. This patch trivially
adds the call and a test.
BUG=v8:4125
R=adamk
LOG=Y
Review URL: https://codereview.chromium.org/1178193004
Cr-Commit-Position: refs/heads/master@{#28972}
%AddElement is not intended for objects which are not arrays, and
its behavior may go away with future refactorings. This patch gets
rid of it if the receiver of from or of is not the intrinsic Array
object.
Array.of and Array.from previously papered over failures in calling
[[DefineOwnProperty]] when setting array elements. This patch
makes them lead to exceptions, and adds tests to assert that
the appropriate exceptions are thrown.
BUG=v8:4168
R=adamk
CC=rossberg,verwaest
LOG=Y
Review URL: https://codereview.chromium.org/1181623003
Cr-Commit-Position: refs/heads/master@{#28969}
The main motivation is simplifying profiling activities:
1) Use hex instead of decimal for offsets, just like perf does. This
affects --print-opt-code
2) When printing block information, indicate loop information: if
block is header, where the end is; if block is in a loop, where the
loop starts. This affects --code-comments.
Using --print-opt-code --code-comments, and cross-referencing with data
obtained from perf, one may now find the block a hotspot belongs to
without needing to do hex2dec/dec2hex conversions. Once found, loop info
is available locally, on the block.
BUG=
Review URL: https://codereview.chromium.org/1177123002
Cr-Commit-Position: refs/heads/master@{#28964}
Reason for revert:
Blocks revert of https://codereview.chromium.org/1175973002
Original issue's description:
> Replace SetObjectProperty / DefineObjectProperty with less powerful alternatives where relevant.
>
> @yangguo: please look at the debugger part of the CL.
> @ishell: please look at the rest.
>
> Additionally:
> - Ensure the LookupIterator for named properties does not accidentally get indexes in.
> - Fix the return value for typed array assignments to be the incoming value.
>
> BUG=v8:4137
> LOG=n
>
> Committed: https://crrev.com/15aa811f8fe2708a757c3b53ca89db736aa8b222
> Cr-Commit-Position: refs/heads/master@{#28954}
TBR=yangguo@chromium.org,verwaest@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4137
Review URL: https://codereview.chromium.org/1181733002
Cr-Commit-Position: refs/heads/master@{#28957}
@yangguo: please look at the debugger part of the CL.
@ishell: please look at the rest.
Additionally:
- Ensure the LookupIterator for named properties does not accidentally get indexes in.
- Fix the return value for typed array assignments to be the incoming value.
BUG=v8:4137
LOG=n
Review URL: https://codereview.chromium.org/1178503004
Cr-Commit-Position: refs/heads/master@{#28954}
port dd85444951 (r28839)
original commit message:
Boolean "is_strong" parameters have begun to proliferate across areas where
strong mode semantics are different. This CL repurposes the existing
ObjectStrength enum as a replacement for them.
BUG=
R=weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/1173973002
Cr-Commit-Position: refs/heads/master@{#28952}
port 345fa142a9 (r28802).
port of r28769 overwrite some of r28802 so we port them again.
original commit message:
Before this we had 3 super related lexical bindings that got injected
into method bodies: .home_object, .this_function, and new.target.
With this change we get rid of the .home_object one in favor of using
.this_function[home_object_symbol] which allows some simplifications
throughout the code base.
BUG=
R=weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/1173933005
Cr-Commit-Position: refs/heads/master@{#28949}
port e4782a9b46 (r28782)
original commit message:
Previously the %_DateField intrinsic would also check the object and
throw an exception if you happen to pass something that is not a valid
JSDate, which (a) violates our policy for instrinsics and (b) is hard to
optimize in TurboFan (even Crankshaft has a hard time, but there we will
never inline the relevant builtins, so it doesn't show up). The throwing
part is now a separate intrinsics %_ThrowIfNotADate that throws an
exception in full codegen and deoptimizes in Crankshaft, which means the
code for the current use cases is roughly the same (modulo some register
renamings/gap moves).
BUG=
R=weiliang.lin@intel.com
Review URL: https://codereview.chromium.org/1174913002
Cr-Commit-Position: refs/heads/master@{#28948}
Merge a following arithmetic or logical right shift into the existing shift
of ARM64's Int32MulHigh or Uint32MulHigh code.
BUG=
Review URL: https://codereview.chromium.org/1179503003
Cr-Commit-Position: refs/heads/master@{#28945}
Reason for revert:
Breaks InstructionSelectorTest.Word64ShrWithWord64AndWithImmediate on debug builds (but not optdebug builds). I'll investigate.
Original issue's description:
> [arm64][turbofan]: Handle any immediate shift.
>
> With this patch, we can generate simple immediate-shift instructions for
> immediates outside the range "0 <= imm < width". Several related
> instruction selectors have also been updated accordingly.
>
> Example of generated code:
>
> ---- Before --- ---- After ----
> movz w0, #33 lsr w0, w1, #1
> lsr w0, w1, w0
>
> BUG=
>
> Committed: https://crrev.com/36d771bbfa4af5efcc1c1dcf5b234445cb7ee722
> Cr-Commit-Position: refs/heads/master@{#28943}
TBR=bmeurer@chromium.org,ulan@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1176393002
Cr-Commit-Position: refs/heads/master@{#28944}
With this patch, we can generate simple immediate-shift instructions for
immediates outside the range "0 <= imm < width". Several related
instruction selectors have also been updated accordingly.
Example of generated code:
---- Before --- ---- After ----
movz w0, #33 lsr w0, w1, #1
lsr w0, w1, w0
BUG=
Review URL: https://codereview.chromium.org/1179733004
Cr-Commit-Position: refs/heads/master@{#28943}
The alternative of passing an object template at context creation is
unfeasible because we need a context to instantiate the template.
At the time we create the context from snapshot or bootstrap from
scratch, we would already need that template instance, leading to a
chicken-and-egg problem.
This is an alternative that is simpler and less intrusive.
R=domenic@chromium.org, jochen@chromium.org
Review URL: https://codereview.chromium.org/1182443002
Cr-Commit-Position: refs/heads/master@{#28938}
Uniformly use the Heap::GetRootListIndex() and
Heap::RootIsImmortalImmovable() methods to detect immortal immovable
roots in the optimizing compilers.
R=jarin@chromium.org
Review URL: https://codereview.chromium.org/1178853002
Cr-Commit-Position: refs/heads/master@{#28933}
Reason for revert:
Revert, due to problems with stale build artefacts uncovered by this.
Details: https://code.google.com/p/v8/issues/detail?id=4171
Original issue's description:
> Re-land: Enable external startup by default on Linux.
>
> crrev.com/1016603004 should have fixed the issues that broke this last time.
>
> Notes:
> - The current functionality is meant to stay. If you prefer the old way,
> just set v8_use_external_startup_data=0.
> - You might notice this if you call d8 via PATH. Either explicitly tell d8
> where your external snapshot/built-ins are, or change the build options
> as above.
> - This follows Chromium practice, that mostly uses this feature these days.
> - Other platforms to follow later.
>
> BUG=
>
> Committed: https://crrev.com/bb9c774c164c3552b67b4f1b60809852a44f2ecd
> Cr-Commit-Position: refs/heads/master@{#28858}
TBR=jochen@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=
Review URL: https://codereview.chromium.org/1177883003
Cr-Commit-Position: refs/heads/master@{#28929}
Reason for revert:
Test failures are bogus. Snapshot blob and natives blob are out of sync due to build being weird.
Original issue's description:
> Revert of Promise assimilation fix. (patchset #8 id:160001 of https://codereview.chromium.org/1098663002/)
>
> Reason for revert:
> Test failures: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux64/builds/3829
>
> Original issue's description:
> > Promise assimilation fix.
> >
> > Let x be a fulfilled promise and y be another promise. |x.then(() => y)|
> > should call |y.then|, but the current implementation calls PromiseChain.
> > We can see the difference when we set a custom function to |y.then|.
> >
> > This CL fixes the spec violation, but as a result |then| is no longer
> > a wrapper of |chain| and in some cases it does not work well with
> > |accept| or |chain|. That is not a problem for ES6 promise users because
> > ES6 promise doesn't have them.
> >
> > LOG=N
> > BUG=477921
> >
> > Committed: https://crrev.com/2f57dff3ea0c45e1a61b334fda962460f89d71bc
> > Cr-Commit-Position: refs/heads/master@{#28926}
>
> TBR=arv@chromium.org,caitpotter88@gmail.com,rossberg@chromium.org,yhirano@chromium.org
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=477921
>
> Committed: https://crrev.com/5bb75f514027f79303396dba823c2d78c6add83b
> Cr-Commit-Position: refs/heads/master@{#28927}
TBR=arv@chromium.org,caitpotter88@gmail.com,rossberg@chromium.org,yhirano@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=477921
Review URL: https://codereview.chromium.org/1181533006
Cr-Commit-Position: refs/heads/master@{#28928}
Reason for revert:
Test failures: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux64/builds/3829
Original issue's description:
> Promise assimilation fix.
>
> Let x be a fulfilled promise and y be another promise. |x.then(() => y)|
> should call |y.then|, but the current implementation calls PromiseChain.
> We can see the difference when we set a custom function to |y.then|.
>
> This CL fixes the spec violation, but as a result |then| is no longer
> a wrapper of |chain| and in some cases it does not work well with
> |accept| or |chain|. That is not a problem for ES6 promise users because
> ES6 promise doesn't have them.
>
> LOG=N
> BUG=477921
>
> Committed: https://crrev.com/2f57dff3ea0c45e1a61b334fda962460f89d71bc
> Cr-Commit-Position: refs/heads/master@{#28926}
TBR=arv@chromium.org,caitpotter88@gmail.com,rossberg@chromium.org,yhirano@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=477921
Review URL: https://codereview.chromium.org/1176163004
Cr-Commit-Position: refs/heads/master@{#28927}
Let x be a fulfilled promise and y be another promise. |x.then(() => y)|
should call |y.then|, but the current implementation calls PromiseChain.
We can see the difference when we set a custom function to |y.then|.
This CL fixes the spec violation, but as a result |then| is no longer
a wrapper of |chain| and in some cases it does not work well with
|accept| or |chain|. That is not a problem for ES6 promise users because
ES6 promise doesn't have them.
LOG=N
BUG=477921
Review URL: https://codereview.chromium.org/1098663002
Cr-Commit-Position: refs/heads/master@{#28926}
