This stub will be used as the basis of a Math.floor-specific CallIC to
detect and track calls to floor that return -0.
Along the way:
- Create a TurboFanCodeStub super class from which the StringLength and
MathRound TF stubs derive.
- Fix the ugly hack that passes the first stub parameter as the "this"
pointer in the the TF-compiled JS function.
- Fix bugs in the ia32/x64 disassembler.
Review URL: https://codereview.chromium.org/1137703002
Cr-Commit-Position: refs/heads/master@{#28339}
For the moment, we only pass the global object (the one we are setting up).
A few smaller changes were necessary to avoid failures in
test-object-observe/DontLeakContextOnObserve. Otherwise the global object
would be retained by being context allocated, leading to test failure.
R=jkummerow@chromium.org
Review URL: https://codereview.chromium.org/1132513003
Cr-Commit-Position: refs/heads/master@{#28331}
Implements the strong mode proposal's restrictions on implicit conversions
for the binary + operator. Test suite is also cleaned up/refactored to allow
easier testing of the comparison operators in the future.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1109223004
Cr-Commit-Position: refs/heads/master@{#28159}
Implements the strong mode proposal's restrictions on
implicit conversions for binary arithmetic operations, not
including the + special case. Adds some infrastructure
for future implementation of the restrictions for other
operators.
BUG=v8:3956
LOG=N
Review URL: https://codereview.chromium.org/1092353002
Cr-Commit-Position: refs/heads/master@{#28045}
This enables adding more language modes in the future.
For maximum flexibility, LanguageMode is a bitmask, so we're not restricted to
use a sequence of language modes which are progressively stricter, but we can
express the language mode as combination of features.
For now, LanguageMode can only be "sloppy" or "strict", and there are
STATIC_ASSERTS in places which need to change when more modes are added.
LanguageMode is a bit like the old LanguageMode when "extended" mode was still
around (see https://codereview.chromium.org/8417035 and
https://codereview.chromium.org/181543002 ) except that it's transmitted through
all the layers (there's no StrictModeFlag).
BUG=
Review URL: https://codereview.chromium.org/894683003
Cr-Commit-Position: refs/heads/master@{#26419}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, 7d48fd9dc2.
BUG=v8:3754
LOG=Y
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/798243004
Cr-Commit-Position: refs/heads/master@{#26084}
Reason for revert:
[sheriff] Still crashes on win32 (XP):
http://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%201/builds/1380
Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0f4.
>
> This changes to do an early bailout in
> HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
> loop.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.orgTBR=dslomov@chromium.org,arv@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754
Review URL: https://codereview.chromium.org/811593004
Cr-Commit-Position: refs/heads/master@{#25872}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, a76419f0f4.
This changes to do an early bailout in
HOptimizedGraphBuilder::VisitObjectLiteral instead of doing that in the later
loop.
BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/792233008
Cr-Commit-Position: refs/heads/master@{#25868}
Reason for revert:
Crashes Win32. It was not flake.
Original issue's description:
> ES6 computed property names
>
> This adds support for computed property names, under the flag
> --harmony-computed-property-names, for both object literals and
> classes.
>
> This is a revert of the revert, a76419f0f4 with
> no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
> try again.
>
> BUG=v8:3754
> LOG=Y
> TBR=dslomov@chromium.orgTBR=dslomov@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=v8:3754
Review URL: https://codereview.chromium.org/807033003
Cr-Commit-Position: refs/heads/master@{#25853}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
This is a revert of the revert, a76419f0f4 with
no changes. I cannot reproduce the issue on Win8.1 or WinXP. Letting the bots
try again.
BUG=v8:3754
LOG=Y
TBR=dslomov@chromium.org
Review URL: https://codereview.chromium.org/807173002
Cr-Commit-Position: refs/heads/master@{#25851}
This adds support for computed property names, under the flag
--harmony-computed-property-names, for both object literals and
classes.
BUG=v8:3754
LOG=Y
Review URL: https://codereview.chromium.org/795573005
Cr-Commit-Position: refs/heads/master@{#25821}
Add support for Symbol.isConcatSpreadable in Array.prototype.concat. This enables spreading non-Array objects with the symbol.
LOG=N
R=dslomov@chromium.org
BUG=
Review URL: https://codereview.chromium.org/771483002
Cr-Commit-Position: refs/heads/master@{#25808}
This patch introduces a new inline runtime function,
%_HasFastPackedElements(), and uses it both in the implementation
of the 'in' operator and in the array builtins to speed
up testing for the existence of an index in an array.
In testing with the microbenchmark on the attached bug,
for example, the runtime goes from 326ms to 66ms.
A reviewer might ask whether the HAS_INDEX macro is worthwhile,
and I tried the same example without it, which pushed the
microbenchmark up to 157ms. So it seems it's worth it to
avoid the function call to IN() if we know we're dealing
with arrays and numbers.
BUG=v8:3701
LOG=n
Review URL: https://codereview.chromium.org/754863002
Cr-Commit-Position: refs/heads/master@{#25665}
Refresh the implementation of Symbols to catch up with what the
specification now mandates:
* The global Symbol() function manufactures new Symbol values,
optionally with a string description attached.
* Invoking Symbol() as a constructor will now throw.
* ToString() over Symbol values still throws, and
Object.prototype.toString() stringifies like before.
* A Symbol value is wrapped in a Symbol object either implicitly if
it is the receiver, or explicitly done via Object(symbolValue) or
(new Object(symbolValue).)
* The Symbol.prototype.toString() method no longer throws on Symbol
wrapper objects (nor Symbol values.) Ditto for Symbol.prototype.valueOf().
* Symbol.prototype.toString() stringifies as "Symbol("<description>"),
valueOf() returns the wrapper's Symbol value.
* ToPrimitive() over Symbol wrapper objects now throws.
Overall, this provides a stricter separation between Symbol values and
wrapper objects than before, and the explicit fetching out of the
description (nee name) via the "name" property is no longer supported
(by the spec nor the implementation.)
Adjusted existing Symbol test files to fit current, adding some extra
tests for new/changed behavior.
LOG=N
R=arv@chromium.org, rossberg@chromium.org, arv, rossberg
BUG=v8:3053
Review URL: https://codereview.chromium.org/118553003
Patch from Sigbjorn Finne <sigbjornf@opera.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19490 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
