On 2015/12/17 at 21:30:35, Dan Ehrenberg wrote:
On 2015/12/17 at 18:48:42, commit-bot wrote:
> Patchset 25 (id:??) landed as
https://crrev.com/70a7c754bf3445a8b783b75ca2a7aa34cdeb080b
> Cr-Commit-Position: refs/heads/master@{#32959}
This breaks my interactive builds of V8.
Oh sorry, this w
On 2015/12/17 at 18:48:42, commit-bot wrote:
Patchset 25 (id:??) landed as
https://crrev.com/70a7c754bf3445a8b783b75ca2a7aa34cdeb080b
Cr-Commit-Position: refs/heads/master@{#32959}
This breaks my interactive builds of V8.
https://codereview.chromium.org/988893003/
--
--
v8-dev mailing list
https://codereview.chromium.org/1332873003/diff/160001/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1332873003/diff/160001/src/parser.cc#newcode4974
src/parser.cc:4974: for (auto delegate : *delegates) {
On 2015/09/17 at 19:20:06, adamk wrote:
With the renaming, I t
https://codereview.chromium.org/1332873003/diff/120001/src/ast.h
File src/ast.h (right):
https://codereview.chromium.org/1332873003/diff/120001/src/ast.h#newcode1276
src/ast.h:1276: class DelegateStatement final : public Statement {
On 2015/09/17 at 18:44:36, adamk wrote:
I thought this was goi
PTAL
https://codereview.chromium.org/1332873003/diff/80001/test/mjsunit/harmony/block-sloppy-function.js
File test/mjsunit/harmony/block-sloppy-function.js (right):
https://codereview.chromium.org/1332873003/diff/80001/test/mjsunit/harmony/block-sloppy-function.js#newcode7
test/mjsunit/harmony/
Haven't figured out tests for this scoping issue, but fixed all the other
review
comments
https://codereview.chromium.org/1332873003/diff/80001/src/ast.h
File src/ast.h (right):
https://codereview.chromium.org/1332873003/diff/80001/src/ast.h#newcode1273
src/ast.h:1273: // Delegates to another
Reviewers: adamk, rossberg,
Description:
Implement sloppy-mode block-defined functions (Annex B 3.3)
ES2015 specifies very particular semantics for functions defined in blocks.
In strict mode, it is simply a lexical binding scoped to that block. In
sloppy
mode, in addition to that lexical bin
lgtm
Code looks good to me. I am still worried about performance though. Could
you
run some benchmarks which hit the path before committing? Either that or be
prepared to back it out later when the regression becomes apparent.
https://codereview.chromium.org/1309243003/
--
--
v8-dev mailing
lgtm
https://codereview.chromium.org/1324353002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
Other than style, looks good to me.
https://codereview.chromium.org/1324353002/diff/20001/src/string.js
File src/string.js (right):
https://codereview.chromium.org/1324353002/diff/20001/src/string.js#newcode1041
src/string.js:1041: return true;
There's some code duplication between these two fu
lgtm
https://codereview.chromium.org/1332463002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
lgtm
https://codereview.chromium.org/1306753007/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
On 2015/09/04 at 18:27:11, Dan Ehrenberg wrote:
On 2015/09/04 at 18:20:36, commit-bot wrote:
> Dry run: Try jobs failed on following builders:
> v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/5566)
** Presubmit Warnings **
k...
On 2015/09/04 at 18:20:36, commit-bot wrote:
Dry run: Try jobs failed on following builders:
v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/5566)
** Presubmit Warnings **
k...@skomski.com is not in AUTHORS file. If you are a ne
lgtm
https://codereview.chromium.org/1321853006/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
I think you'll have to upload a separate, new patch to commit this.
https://codereview.chromium.org/1305923005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
lgtm
https://codereview.chromium.org/1305923005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
lgtm
https://codereview.chromium.org/1305033005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
Reviewers: adamk,
Description:
Stage sloppy let
Move the --harmony-sloppy-let flag to staging for further testing, and
update test262 for the new passing tests. Also increase the strictness
of the parser, even in sloppy mode, to disallow "new legacy compat" for
for (let x = 5 in {}) {}
which
A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/1324033002/ by little...@chromium.org.
The reason for reverting is: Fails a test262 test with --always-opt..
https://codereview.chromium.org/1327483002/
--
--
v8-dev mailing list
v8-dev@googlegroups.
Reviewers: adamk,
Message:
Created Revert of Stage sloppy let
Description:
Revert of Stage sloppy let (patchset #7 id:120001 of
https://codereview.chromium.org/1327483002/ )
Reason for revert:
Fails a test262 test with --always-opt.
Original issue's description:
Stage sloppy let
Move the -
Reviewers: adamk,
Description:
Stage sloppy let
Move the --harmony-sloppy-let flag to staging for further testing, and
update test262 for the new passing tests. Also increase the strictness
of the parser, even in sloppy mode, to disallow "new legacy compat" for
for (let x = 5 in {}) {}
which
Reviewers: adamk,
Description:
Make Date.prototype an ordinary object
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
Ple
Reviewers: adamk,
Description:
Propagate switch statement value for 'eval'
This patch changes the switch scope desugaring to create blocks which
propagate their 'return value' for eval.
BUG=v8:4399
R=adamk
LOG=Y
Please review this at https://codereview.chromium.org/1309303006/
Base URL: https
Reviewers: adamk, vogelheim,
Message:
This was previously reviewed at https://codereview.chromium.org/1295883002 ;
uploaded here because I couldn't get Rietveldt to resume a patch from a
different checkout when there were conflicts in the cherry-pick.
Compared to the last version, this version t
lgtm
https://codereview.chromium.org/1305923005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
On 2015/08/27 at 16:21:04, adamk wrote:
Your reasoning re: ScopeInfo sounds right to me. Can you add a note to
scopes.h explaining why the bit isn't needed on ScopeInfo?
Also, could you add a few more tests (the ones suggested by Andreas)? In
particular, tests for assignment and loading insid
On 2015/08/27 at 01:40:49, Dan Ehrenberg wrote:
Could we leave tracking nonlinear scopes in ScopeInfo for a future patch?
This
one brings the world further towards correctness as-is. And I'm not sure
how to
trigger a test case--everything I try just works.
https://codereview.chromium.org/13
Could we leave tracking nonlinear scopes in ScopeInfo for a future patch?
This
one brings the world further towards correctness as-is. And I'm not sure
how to
trigger a test case--everything I try just works.
https://codereview.chromium.org/1312613003/diff/60001/src/full-codegen/full-codegen
Modulo the apparent test failure, looks good to me.
https://codereview.chromium.org/1304183004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe f
lgtm
Oops!
https://codereview.chromium.org/1315993002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails
On 2015/08/26 at 00:40:26, adamk wrote:
lgtm
Looks like this was a lot easier than last time!
Well I fixed something small upstream, but the big help was that there's
been a
minor backlog of code reviews :)
https://codereview.chromium.org/1317723003/
--
--
v8-dev mailing list
v8-dev@goo
Reviewers: adamk,
Description:
--harmony-sloppy-function depends on --harmony-sloppy
The lack of marking this dependency led to a ClusterFuzz crash when
sloppy-function was on but not sloppy. This case does not make sense.
R=adamk
LOG=N
BUG=chromium:520891
Please review this at https://coderev
Reviewers: adamk,
Description:
Test262 roll to the 2015-8-25 version
Please review this at https://codereview.chromium.org/1317723003/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+2, -2 lines):
M test/test262-es6/testcfg.py
Index: test/test262-es6/testcfg.p
https://codereview.chromium.org/1312613003/diff/40001/src/full-codegen/full-codegen.cc
File src/full-codegen/full-codegen.cc (right):
https://codereview.chromium.org/1312613003/diff/40001/src/full-codegen/full-codegen.cc#newcode1601
src/full-codegen/full-codegen.cc:1601: DCHECK(var->location() =
https://codereview.chromium.org/1312613003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, sen
lgtm
Looks pretty straightforward!
https://codereview.chromium.org/1307943007/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group a
lgtm
https://codereview.chromium.org/1302133002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
lgtm
https://codereview.chromium.org/1303013007/diff/1/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1303013007/diff/1/src/parser.cc#newcode4390
src/parser.cc:4390: CheckConflictingVarDeclarations(param_scope,
CHECK_OK);
Not new in this patch, but I'm wondering why
lgtm
https://codereview.chromium.org/1306723005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
lgtm
https://codereview.chromium.org/1308213003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
Reviewers: adamk,
Description:
Unship TypedArray.map method
The TypedArray.map method breaks a particular Chrome app, which
conditionally
monkey-patches in an unrelated function with the same name, but only if that
property does not exist. The developer already has a fix, but it is not
deploy
https://codereview.chromium.org/1312613003/diff/20001/src/full-codegen/arm/full-codegen-arm.cc
File src/full-codegen/arm/full-codegen-arm.cc (right):
https://codereview.chromium.org/1312613003/diff/20001/src/full-codegen/arm/full-codegen-arm.cc#newcode1471
src/full-codegen/arm/full-codegen-arm.c
Reviewers: adamk,
Message:
The test still fails on TurboFan; I'm investigating.
Description:
Ensure hole checks take place in switch statement scopes
Switch statements introduce their own scope for cases, but this scope
is not necessarily executed in order, as the following function shows:
s
lgtm
Yay for testing!
https://codereview.chromium.org/1312703003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop recei
Reviewers: adamk,
Description:
Add a separate scope for switch
The ES2015 specification for switch statements 13.12.11 specifies that
they get their own lexical scope. This patch introduces such a scope
through a complex desugaring in terms of blocks, done so that Crankshaft
does not have to be
Reviewers: Benedikt Meurer,
Description:
Translate AST to Hydrogen missing position
This patch translates RelocInfo::kNoPosition to SourcePosition::Unknown()
in constructing the Hydrogen graph from the parser's output. The translation
is done to increase the flexibility of the parser to desugar
Reviewers: adamk,
Message:
Created Revert of Add a separate scope for switch
Description:
Revert of Add a separate scope for switch (patchset #7 id:120001 of
https://codereview.chromium.org/1293283002/ )
Reason for revert:
Breaks cctest/test-cpu-profiler/SourceLocation on nosnap
Original issue
A revert of this CL (patchset #7 id:120001) has been created in
https://codereview.chromium.org/1309043004/ by little...@chromium.org.
The reason for reverting is: Breaks cctest/test-cpu-profiler/SourceLocation
on
nosnap.
https://codereview.chromium.org/1293283002/
--
--
v8-dev mailing list
- Unsigned int types should also have load and store functions
- To test, try removing the code in the simdjs tests which loads the
polyfill,
and run the tests anyway. At this point, we should have all functions
implemented, right?
https://codereview.chromium.org/1302133002/
--
--
v8-dev mail
The code looks good, but could you add some tests that verify the behavior?
This
could be in the form of somehow verifying that the polyfill's tests are
executing against your load functions, rather than the polyfill-provided
ones.
https://codereview.chromium.org/1302133002/
--
--
v8-dev ma
https://codereview.chromium.org/1293283002/diff/11/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1293283002/diff/11/src/parser.cc#newcode2982
src/parser.cc:2982: factory()->NewBlock(labels, 2, true,
RelocInfo::kNoPosition);
On 2015/08/21 at 01:19:08, adamk wro
https://codereview.chromium.org/1303033003/diff/20001/test/mjsunit/regress/regress-520029.js
File test/mjsunit/regress/regress-520029.js (right):
https://codereview.chromium.org/1303033003/diff/20001/test/mjsunit/regress/regress-520029.js#newcode28
test/mjsunit/regress/regress-520029.js:28: try
Reviewers: adamk,
Description:
Fix function scoping issue
The parser has special behavior with respect to the bindings
of inner functions in sloppy mode which are not at the top
level of scopes. This behavior should be turned off when the
--harmony-sloppy-function flag is set, as lexical scoping
Reviewers: adamk,
Description:
Add a separate scope for switch
The ES2015 specification for switch statements 13.12.11 specifies that
they get their own lexical scope. This patch introduces such a scope
through a complex desugaring in terms of blocks, done so that Crankshaft
does not have to be
lgtm
Such a weird spec, but your implementation makes sense. I can't think of a
simpler way. Why don't the default parameter direct evals just run within
the
function's existing var scope? (Or, why 1JS?!)
https://codereview.chromium.org/1292753007/
--
--
v8-dev mailing list
v8-dev@googlegrou
lgtm
https://codereview.chromium.org/1294513004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
Reviewers: cbruni,
Message:
I am a little hesitant to push ahead with this strategy until we have
benchmarks
to show it doesn't give a regression. In particular, I wanted to test the
performance of this patch against the baseline, and also against just not
having
the builtin at all and going
lgtm
Wow, very well-tested.
https://codereview.chromium.org/1237583005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop
https://codereview.chromium.org/1295883002/diff/60001/src/scanner.h
File src/scanner.h (right):
https://codereview.chromium.org/1295883002/diff/60001/src/scanner.h#newcode547
src/scanner.h:547: (current_.literal_chars == &literal_buffers_[0])
On 2015/08/17 at 18:24:39, adamk wrote:
On 2015/08/1
I ran Octane locally three times with and without this patch. I measured a
2.3%
regression caused by the patch in CodeLoad. Where do we go from here? I am
having trouble figuring out a clean strategy for avoiding the conditional by
pushing back all the way into the stream, though I can imagine s
https://codereview.chromium.org/1295883002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, sen
Actually, the performance runs didn't show a big regression: On
v8_linux64_haswell_perf_try, CodeLoad was up 0.1, and on
v8_linux32_perf_try,
CodeLoad was down just 0.4%. However, these tests seem to be very volatile.
Does
anyone have an idea for getting more reliable results before submitti
Reviewers: adamk,
Message:
This is currently more of an RFC because of the indeterminate performance
impact. It should not be merged before the 46 branch.
Description:
Sloppy-mode let parsing
This patch makes 'let' a contextual keyword in both strict and sloppy mode.
It behaves as a keyword whe
Reviewers: adamk,
Description:
Stage sloppy classes
This patch puts --harmony-sloppy into staging. Now that let,
lexically-scoped
functions and ES2015 sloppy mode const semantics have been split off into
separate flags, the change only enables classes in sloppy mode.
BUG=v8:3305
R=adamk
LOG=
Fixed the issues, thanks.
https://codereview.chromium.org/1286923002/diff/1/test/mjsunit/es6/block-scoping.js
File test/mjsunit/es6/block-scoping.js (right):
https://codereview.chromium.org/1286923002/diff/1/test/mjsunit/es6/block-scoping.js#newcode282
test/mjsunit/es6/block-scoping.js:282: //a
Reviewers: adamk,
Description:
Add class to existing lexical scoping tests
This patch strengthens testing of classes by verifying that the binding
that they export externally follows block scoping, as opposed to var-style
scoping. The tests are based on existing tests for let and const.
R=adamk
https://codereview.chromium.org/1282093002/diff/60001/src/flag-definitions.h
File src/flag-definitions.h (right):
https://codereview.chromium.org/1282093002/diff/60001/src/flag-definitions.h#newcode191
src/flag-definitions.h:191: V(harmony_block_function, "harmony function
block scoping") \
On
PTAL
https://codereview.chromium.org/1282093002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from i
https://codereview.chromium.org/1274193004/diff/40001/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1274193004/diff/40001/src/parser.cc#newcode2019
src/parser.cc:2019: declaration_scope->is_strict_eval_scope() ||
On 2015/08/11 at 01:17:43, adamk wrote:
I think it wou
lgtm
https://codereview.chromium.org/1283703004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
24ad4d60092f69ed73c2d9d18aede7eb196
100644
--- a/test/mjsunit/harmony/block-conflicts-sloppy.js
+++ b/test/mjsunit/harmony/block-conflicts-sloppy.js
@@ -44,12 +44,10 @@ function TestAll(expected,s,opt_e) {
var e = "";
var msg = s;
if (opt_e) { e = opt_e; msg += opt_e; }
- // TODO(
lgtm
https://codereview.chromium.org/1282013002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
On 2015/08/08 00:00:12, commit-bot: I haz the power wrote:
Dry run: Try jobs failed on following builders:
v8_mac_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_mac_rel/builds/8499)
I should've waited for the tests to finish before mailing... I guess we
Reviewers: adamk,
Description:
Function declarations scope normally with --harmony_sloppy
In an initial attempt to implement sloppy mode lexical bindings,
functions were made lexically scoped in sloppy mode. However, the
ES2015 spec says that they need an additional hoisted var binding,
and furt
Reviewers: adamk,
Description:
Delete outdated comment about a bug which was fixed three years ago
R=adamk
BUG=chromium:135066
LOG=N
Please review this at https://codereview.chromium.org/1279203002/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+1, -4 lines):
Reviewers: adamk,
Description:
Reland "Test262 roll"
Reland patch originally reviewed at
https://codereview.chromium.org/1268553003/
This new patch marks a test [PASS, FAIL] since it passes on some platforms.
Please review this at https://codereview.chromium.org/1273883005/
Base URL: https
Reviewers: adamk,
Description:
Update to latest test262 from 2015-07-31
Please review this at https://codereview.chromium.org/1268553003/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+347, -166 lines):
M test/test262-es6/test262-es6.status
M test/test262-es6
lgtm
https://codereview.chromium.org/1230343003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
Sorry for the long turnaround time. Just a couple changes needed; the
denormal/reciprocal approximation stuff can wait for now. I'm happy with
how you
were able to use C macros to get rid of most of the duplication here.
https://codereview.chromium.org/1230343003/diff/140001/src/harmony-simd.
Reviewers: adamk,
Description:
Class block scoping tests
Class bindings are mutable and lexically scoped, with TDZ semantics.
They may not overlap with var bindings in the same scope. This patch
adds tests for those properties.
R=adamk
BUG=3305
LOG=N
Please review this at https://codereview.ch
Reviewers: adamk,
Description:
Split off a separate --harmony_sloppy_let flag
--harmony_sloppy includes behavior to turn on sloppy mode lexical
bindings. Before this patch, it also included a way to parse let
which is likely web-incompatible (let is disallowed as an
identifier). This patch split
On 2015/07/24 18:17:00, Dan Ehrenberg wrote:
Are you sure you chose this patch correctly? When I run the failing test
locally, including the patch that you reverted, it passes.
Oh, sorry, following those precise instructions that Yang mailed, I can
reproduce the error. And the rollback fixes it
Are you sure you chose this patch correctly? When I run the failing test
locally, including the patch that you reverted, it passes.
https://codereview.chromium.org/1254723005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message b
Reviewers: adamk,
Description:
Revert "In RegExp, lastIndex is read with ToLength, not ToInteger"
$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=chr
lgtm
https://codereview.chromium.org/1242863003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
lgtm
https://codereview.chromium.org/1242623002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
lgtm
https://codereview.chromium.org/1240453003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from
+1!
https://codereview.chromium.org/1240453003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it
https://codereview.chromium.org/1232843005/diff/20001/test/mjsunit/es6/typedarray.js
File test/mjsunit/es6/typedarray.js (right):
https://codereview.chromium.org/1232843005/diff/20001/test/mjsunit/es6/typedarray.js#newcode421
test/mjsunit/es6/typedarray.js:421: var d =
Object.getOwnPropertyDescr
Reviewers: adamk,
Description:
Split off ParserBase into src/parser-base.h
Previously, the PreParser and ParserBase (used by both the
preparser and the parser) where in the same file. Splitting
them into separate files makes the code easier to navigate.
R=adamk
Please review this at https://co
https://codereview.chromium.org/1238593003/diff/40001/src/array.js
File src/array.js (left):
https://codereview.chromium.org/1238593003/diff/40001/src/array.js#oldcode571
src/array.js:571: if (!IS_UNDEFINED(current_i) || low in array) {
On 2015/07/16 22:08:13, adamk wrote:
As discussed offline,
PTAL
https://codereview.chromium.org/1238593003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from i
PTAL
https://codereview.chromium.org/1238593003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from i
On 2015/07/16 20:06:24, adamk wrote:
I would tend to agree that this behavior change isn't going to break real
code.
Just slightly annoyed by all the spec churn (as we burn down the list of
ES6
bugs).
Seems strange to optimize for proxies here, if that's all it was, when it's
a
pessimizat
Reviewers: adamk,
Description:
Fix attributes of TypedArray properties
Some need to be configurable and are currently non-configurable,
and vice versa.
R=adamk
Please review this at https://codereview.chromium.org/1236033010/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affec
On 2015/07/16 15:39:51, commit-bot: I haz the power wrote:
Patchset 1 (id:??) landed as
https://crrev.com/1251d02e7bb2a13ae5cf6fda5d3403730d2ae12f
Cr-Commit-Position: refs/heads/master@{#29708}
Looks like this might have caused a regression: The octane gbemu-part1 test
timed out. Could it be fr
getter deletes elements. ES5 put
the
+// [[HasElement]] after the [[Get]].
+// TODO(littledan): Add a test which triggers the sparse codepath. Below,
the
+// non-sparse codepath is tested.
+
+assertTrue(1 in Array.prototype.reverse.call(
+{length:2, get 0(){delete this[0];}, 1: "b"
Reviewers: adamk,
Description:
Test that TypedArray properties cannot be set in strict mode
Properties like %TypedArray%.prototype.length have a getter and no
setter. This test verifies that property, which was apparently not
true in the past or had no test ensuring throwing in this case.
BUG=v
On 2015/07/15 00:35:52, adamk wrote:
It looks to me like the test262 only exercises one of these code paths,
though
surprisingly it's the test() codepath (not exec(), despite the test262
directory). Can you also add a test for the exec() case?
I have a pull request out at https://github.com/t
1 - 100 of 166 matches
Mail list logo
