Remove some non-standard code that doesn't do anything anyways.
While FireFox uses this to set the default value for the multiline flag,
it is nonstandard and slated for removal. The matching behaviour has
never been implemented in either JSC or V8, so there is little
web-compat risk.
The only possible risk could be someone depending on the ToBoolean()
behaviour of the flag, but this seems unlikely.
BUG=v8:3870
LOG=N
R=adamk@chromium.org, littledan@chromium.org, yangguo@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/1417733012
Cr-Commit-Position: refs/heads/master@{#31882}
This patch moves ES2015 ToLength semantics on array operations, etc
to from staging to shipping.
R=adamk
BUG=v8:3087
LOG=Y
Review URL: https://codereview.chromium.org/1433473003
Cr-Commit-Position: refs/heads/master@{#31810}
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}
Reason for revert:
[Sheriff] Causes layout test failures.
Original issue's description:
> Remove RegExp.multiline accessors.
>
> This is non-standard and not even documented on MDN.
>
> On Firefox, setting RegExp.multiline to true adds the multiline flag to all
> newly created RegExp objects (both from constructor and from literal).
>
> In V8 this has no effect.
>
> Source archaelogy shows that this is from the initial commit.
>
> R=bmeurer@chromium.org
>
> Committed: https://crrev.com/e8f752ce0c2a488e88cd87fe75f3907b4303d0a0
> Cr-Commit-Position: refs/heads/master@{#31673}
TBR=bmeurer@chromium.org,yangguo@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1431433004
Cr-Commit-Position: refs/heads/master@{#31679}
This is non-standard and not even documented on MDN.
On Firefox, setting RegExp.multiline to true adds the multiline flag to all
newly created RegExp objects (both from constructor and from literal).
In V8 this has no effect.
Source archaelogy shows that this is from the initial commit.
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1410993008
Cr-Commit-Position: refs/heads/master@{#31673}
This stages the general purpose inlining mechanism in TurboFan and also
disables the remaining tests that still fail. We do this to get test
coverage early and to avoid regressing inlining as we go along.
R=bmeurer@chromium.org
BUG=v8:4493
LOG=n
Review URL: https://codereview.chromium.org/1412703002
Cr-Commit-Position: refs/heads/master@{#31386}
This is a change for ES2015. Date objects have mutable state, so having
a mutable prototype is bad for SES requirements, and it is an
inconsistency from the typical ES2015 class style of objects
BUG=v8:4004
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1317403002
Cr-Commit-Position: refs/heads/master@{#30486}
$toLength is slow, causing a 3.8%-8% regression in the Octane RegExp
benchmark. Reverting this patch brings it back up. To make this change,
we'll need a faster implementation fo $toLength.
BUG=chromium:513160
LOG=Y
R=adamk
Review URL: https://codereview.chromium.org/1243053005
Cr-Commit-Position: refs/heads/master@{#29830}
ES2015 made a change vs ES5, where the "lastIndex" property of a
RegExp (which can be modified by a user to start the next search at
a different location) is cast to an integer with ToLength rather
than ToInteger. The main difference is on negative numbers, and
this is tested by test262. This patch implements that change on
RegExps and enables the test262 test now that it passes.
R=adamk
LOG=Y
BUG=v8:4244
Review URL: https://codereview.chromium.org/1241713004
Cr-Commit-Position: refs/heads/master@{#29715}
This enables eager optimization of top-level code with TurboFan and
extends test coverage by triggering it with the --always-opt flag.
Script contexts are now also properly allocated in TurboFan.
R=titzer@chromium.org
Review URL: https://codereview.chromium.org/1053063003
Cr-Commit-Position: refs/heads/master@{#27633}
ES6 specs the function length property (it was not part of ES5) and
it makes it configurable.
BUG=v8:3045
LOG=N
R=mstarzinger@chromium.org, adamk@chromium.org
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Review URL: https://codereview.chromium.org/993073002
Cr-Commit-Position: refs/heads/master@{#27190}
There are separated JS and C stacks on simulators so for some stack
extensive tests (like mozilla/js1_5/extensions/regress-355497) might
cause a C stack overflow and that overflow is not caught by V8. It is
not an issue on real HW. Increasing the C stack also solves the problem
but we have already FLAG_sim_stack_size flag to control the JS stack
size.
This patch makes it possible to add flags to tests conditionally in
.status files.
TEST=mozilla/js1_5/extensions/regress-355497
BUG=v8:3152
LOG=N
Review URL: https://codereview.chromium.org/735723006
Cr-Commit-Position: refs/heads/master@{#25434}
Added a new %HasComplexElements runtime function (meaning elements that are
non-writable, non-configurable, or have getters and setters) and use it
in UseSparseVariant to filter out cases where the sparse optimizations
can cause V8 to fall out of spec compliance.
Renamed SmartMove/SmartSlice to SparseMove/SparseSlice and guarded them
with the new and improved UseSparseVariant.
These two changes combine let us pass nearly every test in bug-2615.js,
as well as fixing reverse and join on sparse arrays.
Note that there are various test changes in this patch that correct existing
tests to match the correct-by-spec behavior.
This patch depends on https://codereview.chromium.org/666883009, which
better-aligns the behavior of SmartMove with SimpleMove.
BUG=v8:2615,v8:3612,v8:3621
LOG=y
R=mstarzinger@chromium.org
Review URL: https://codereview.chromium.org/656423004
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@24855 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Legacy const is changed so that a declaration declares a configurable, but non-writable, slot, and the initializer reconfigures it (when possible) to non-configurable non-writable. This avoids the need for "the hole" as marker value in JSContextExtensionObjects and GlobalObjects. Undefined is used instead.
BUG=
R=rossberg@chromium.org
Review URL: https://codereview.chromium.org/379893002
git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@22379 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Important notices:
- The snapshot cannot be created for big-endian target in cross-compilation
environment on little-endian host using simulator.
- In order to have i18n support working on big-endian target, the icudt46b.dat and
icudt46b_dat.S files should be generated and upstreamed to ICU repo.
- The mjsunit 'nans' test is endian dependent, it is skipped for mips target.
- The zlib and Mandreel from Octane 2.0 benchmark are endian dependent due to
use of typed arrays.
TEST=
BUG=
R=jkummerow@chromium.org, plind44@gmail.com
Review URL: https://codereview.chromium.org/228943009
Patch from Dusan Milosavljevic <Dusan.Milosavljevic@rt-rk.com>.
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@20778 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Code generation would fail when assembling a branch to a label that is bound
outside the immediate range of the instruction. A64 is sensitive to this, as the
various branching instructions have different ranges, going down to +-32KB for
TBZ/TBNZ. The MacroAssembler is augmented to handle branches to targets that
may exceed the immediate range of instructions.
When branching backward to a label exceeding the instruction range, the
MacroAssembler can simply tweak the generated code to use an unconditional
branch with a longer range. For example instead of
B(cond, &label);
the MacroAssembler can generate:
b(InvertCondition(cond), &done);
b(&label);
bind(&done);
Since the target is not known when the branch is emitted, forward branches uses
a different mechanism. The MacroAssembler keeps track of forward branches to
unbound labels. When the code generation approaches the end of the range of a
branch, a veneer is generated for the branch.
BUG=v8:3148
LOG=Y
R=ulan@chromium.org
Review URL: https://codereview.chromium.org/169893002
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@19444 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Transformed variant flags into named variants. Now, all combinations of variants can be specified on the command line. The old command-line flags are kept for backwards compatibility on the bots.
Added two new test groups: slow and pass|fail. Both are implemented similar to the flaky test feature and allow to either skip or run tests marked as slow or as pass|fail.
R=yangguo@chromium.org
Review URL: https://codereview.chromium.org/85733003
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@18062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
In the traditional MIPS naming scheme, "mips" is used for
big-endian mips and "mipsel" is used for little-endian mips.
In V8 the "mips" build is little-endian, so the "mips" target is
renamed to "mipsel" to be compliant with the traditional MIPS
naming scheme.
This change is also required for supporting the Chromium project on MIPS.
BUG=
TEST=
Review URL: https://chromiumcodereview.appspot.com/10695114
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12047 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
Our Heap::FreeQueuedChunks generates fake inner chunks in large object
pages queued for freeing, so that StoreBuffer::Filter can recognize them
as pages to be freed. This also relies on MemoryChunk::Contains to work
properly, which is why the size field needs to be initialized as well.
R=vegorov@chromium.org
BUG=v8:1817
TEST=mozilla/js1_5/Regress/regress-360969-05
Review URL: http://codereview.chromium.org/8536009
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@9964 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
We now only recognize "native function" when it occurs in extension scripts
(parsing with a non-NULL extension), and only if there is no line-terminator
between "native" and "function" (so that it would otherwise be a Syntax Error).
Preparsing never recognizes native functions, which is acceptable since we
never preparse extension scripts (because we don't allow lazy functions
anyway).
BUG=v8:1097
Review URL: http://codereview.chromium.org/7206020
git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@8326 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
