Hello all,
Please find below a link to a short design doc for adding a young
generation to ExternalPointerTable.
This work is intended to fix
https://bugs.chromium.org/p/v8/issues/detail?id=13640#c31.
https://docs.google.com/document/d/1Pvr4RbG_ZiaYZ-VkE22bSyCOiOntpbSBNJIhv45JTKk/edit
Looking good. Some open questions on my side. I think the runtime bit is
going
to be gnarly because e.g. we never have a loop inside an expression,
currently,
and that is going to throw off all kinds of things in the compiler, seems
to me.
Some more nits. I defer to Adam's review of course.
https://codereview.chromium.org/1272673003/diff/150001/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1272673003/diff/150001/src/parser.cc#newcode4187
src/parser.cc:4187: }
No need for the if, just execute the body
LGTM, thanks for humoring my nitpicking, doing the perfect thing seems
impossible here.
Regarding desugaring: to my limited understanding there is no inlining
hazard;
TF will be able to do just as well with this desugaring as with indexed
arguments access. It seems to me that TF will have to
On 2015/08/31 11:22:53, conradw wrote:
On 2015/08/28 09:54:13, wingo wrote:
>
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.h
> File src/expression-classifier.h (right):
>
>
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.
https://codereview.chromium.org/1272673003/diff/110001/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1272673003/diff/110001/src/parser.cc#newcode3947
src/parser.cc:3947: ReportMessageAt(params_loc,
MessageTemplate::kMalformedArrowFunParamList);
Why is this necessary?
::decode(code_));
On 2015/08/31 13:23:40, caitp wrote:
> On 2015/08/31 13:07:31, wingo wrote:
> > Need more comments about the preconditions, i.e. the result is only
valid
on
> the
> > result of ParseConditionalExpression when the conditional expression
stared
> with
>
Hi :)
On 2015/08/31 13:23:40, caitp wrote:
https://codereview.chromium.org/1272673003/diff/110001/src/parser.cc#newcode4187
src/parser.cc:4187: }
On 2015/08/31 13:07:31, wingo wrote:
> Is this bit specific to this patch or is it a general fix?
Well, it's a mix. See https://code.google.co
On 2015/08/28 10:04:39, wingo wrote:
The late catch in https://codereview.chromium.org/1320673007/ where I
added a
if (*ok == false) return fixed the failure to enforce the yield
restriction
for param initializers of functions that declare 'use strict' in their
bodies
instead of outside
Rebased. While looking at the diff I noticed a place I did a
ValidateFormalParameterInitializer(classifier, ok), but failed to make the
early
return if *ok was false; fixed that. Resubmitting.
https://codereview.chromium.org/1320673007/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.h
File src/expression-classifier.h (right):
https://codereview.chromium.org/1309813007/diff/1/src/expression-classifier.h#newcode158
src/expression-classifier.h:158: void RecordPatternError(const
Scanner::Location loc,
On 2015/08/28 11:18:58, caitp wrote:
The cl description refers to something which is no longer legal js
(language
mode directive in function with non-simple parameter). Is the message
still
correct, or does it need an update?
Thanks for the note! I didn't realize that this is now invalid
@@ TEST(DefaultParametersYieldInInitializers) {
const char* strict_function_context_data[][2] = {
{'use strong'; (function f(, ) { });},
{'use strict'; (function f(, ) { });},
-// TODO(wingo,conradw): These should also signal early errors.
-// {(function f(, ) {'use strong
Updated description to reflect recent spec change, removed invalid tests.
https://codereview.chromium.org/1318253002/
--
--
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
On Fri 28 Aug 2015 13:32, Caitlin Potter caitpotte...@gmail.com writes:
The main reason was about backtracking token streams in the parser being
the only viable strategy (this came up briefly in the last meeting).
It’s covered in the notes at
Reviewers: adamk,
Description:
Disallow yield in default parameter initializers
R=ad...@chromium.org
LOG=N
BUG=v8:4397
Please review this at https://codereview.chromium.org/1320673007/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected files (+119, -11 lines):
M
Reviewers: rossberg,
Description:
In generators, yield cannot be an arrow formal parameter name
Thanks to André Bargull for the report.
BUG=4212
LOG=N
R=rossb...@chromium.org
Please review this at https://codereview.chromium.org/1309523005/
Base URL:
Michael would you mind a look, this is a reland
https://codereview.chromium.org/1315823002/
--
--
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
Reviewers: rossberg,
Message:
A reapplication of https://codereview.chromium.org/1286383005, now that the
rebaseline patch landed on the Blink side.
Description:
Parse arrow functions at proper precedence level
BUG=v8:4211
LOG=Y
R=rossb...@chromium.org
Please review this at
On 2015/08/25 09:34:45, commit-bot: I haz the power wrote:
Dry run: This issue passed the CQ dry run.
I think things are OK but we should probably wait for the layout tests to
cycle
green before applying.
https://codereview.chromium.org/1315823002/
--
--
v8-dev mailing list
Fixed nits. See comment below about spread treatment.
https://codereview.chromium.org/1315823002/diff/20001/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/1315823002/diff/20001/src/preparser.h#newcode2279
src/preparser.h:2279: } else if
On 2015/08/25 10:13:46, wingo wrote:
On 2015/08/25 09:34:45, commit-bot: I haz the power wrote:
Dry run: This issue passed the CQ dry run.
I think things are OK but we should probably wait for the layout tests to
cycle
green before applying.
Actually I dunno, it's clear which test needed
https://codereview.chromium.org/1287063004/diff/60001/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1287063004/diff/60001/src/parser.cc#newcode3916
src/parser.cc:3916: parser_-Check(Token::ASSIGN)) {
How on earth does this work? This function is called after the
, wingo wrote:
How on earth does this work? This function is called after the arrow
function
arguments have been parsed, and its purpose is to transform the
already-parsed
expression into parameters. I can't see how this can possibly do the
right
thing.
You are right, it doesn't make
lgtm
https://codereview.chromium.org/1307223002/
--
--
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 with test nits
https://codereview.chromium.org/1314543005/diff/1/test/cctest/test-parsing.cc
File test/cctest/test-parsing.cc (right):
https://codereview.chromium.org/1314543005/diff/1/test/cctest/test-parsing.cc#newcode3750
test/cctest/test-parsing.cc:3750: // ({a} = {}) = {},
Perhaps
https://codereview.chromium.org/1307223002/diff/1/src/ast.cc
File src/ast.cc (right):
https://codereview.chromium.org/1307223002/diff/1/src/ast.cc#newcode437
src/ast.cc:437: bool is_simple = boilerplate_properties_ != 0 ||
properties()-length() == 0;
I am missing a bit of context. Is
On 2015/08/20 16:21:04, caitp wrote:
Since default parameters are implemented,a similar test case might be
useful there. It mIght end up working out the same way, it's just hard to
see
if
there's a test case like that in test-parsing by grepping, though.
Good idea! Although there are
Fixed nits; PTAL. Thanks :)
https://codereview.chromium.org/1286383005/diff/20001/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/1286383005/diff/20001/src/preparser.h#newcode2288
src/preparser.h:2288: result =
On 2015/08/20 16:50:00, rossberg wrote:
Nit:
On 2015/08/20 13:39:06, commit-bot: I haz the power wrote:
Dry run: CQ is trying da patch. Follow status at
https://chromium-cq-status.appspot.com/patch-status/1306583002/20001
View timeline at
https://chromium-cq-status.appspot.com/patch-timeline/1306583002/20001
I had a hard time finding
Reviewers: rossberg,
Message:
PTAL. This one is pretty serious and probably should be uplifted to beta
(45)
before it becomes stable.
Description:
Fix parsing of arrow function formal parameters
Not all parenthesized AssignmentExpressions whose components are valid
binding patterns are
Reviewers: rossberg,
Message:
+mstarzinger for the TF bits. WDYT Andreas? This patch is to fix a
precedence
corner case that is irritating but IMO not worth uplifting to stable
because of
the invasive aspects. Perhaps it should be applied to dev though so as not
to
inadvertently break
https://codereview.chromium.org/1306583002/diff/60001/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/1306583002/diff/60001/src/preparser.h#newcode3604
src/preparser.h:3604: ArrowFormalParametersUnexpectedToken(classifier);
On 2015/08/20 15:22:57, caitp wrote:
I would note that naming a test strict-formal-parameters as opposed to
arrow
formal parameters can be misleading as arrow function parameters are indeed
StringFormalParameters, which is a strange grammar production in the spec
which
does not imply strict mode, only that params should not be
I took a look yesterday and it looked fine to me, modulo the test failures
of
course. Am OoO today so if you want to land, please poke another reviewer.
Cheers :)
https://codereview.chromium.org/1212473002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
Reviewers: arv,
Message:
Patch 1 is what landed originally. Patch 2 records the source location for
the
callee in lookup eval calls. The error that was originally seen was that
in one
layout test that triggered an error and matched on the backtrace, line
numbers
were off. I have
On 2015/06/25 13:01:52, arv wrote:
LGTM
Pro tip: If you add the following line to the CL description it will run
the
blink and chrome tests before committing:
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_chromium_rel_ng;tryserver.blink:linux_blink_rel
Thanks, and will do!
On 2015/06/24 20:00:48, mtbrandyberry wrote:
On 2015/06/24 19:12:21, commit-bot: I haz the power wrote:
Failed to apply patch for src/ppc/full-codegen-ppc.cc:
While running git apply --index -3 -p1;
error: patch failed: src/ppc/full-codegen-ppc.cc:3148
Falling back to three-way merge...
Reviewers: arv,
Description:
Better error message for eval=42 in strict mode
BUG=v8:4213
R=a...@chromium.org
LOG=N
Please review this at https://codereview.chromium.org/1210003003/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected files (+15, -8 lines):
M src/preparser.h
lgtm
https://codereview.chromium.org/1209703002/
--
--
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: arv, Michael Starzinger,
Message:
PTAL. Another option would be to revert the part of
https://codereview.chromium.org/1178903003 that made
kResolvePossiblyDirectEval
return just one result, and make it take the receiver again, dunno though.
Description:
Fix receiver when calling
On 2015/06/24 11:55:20, wingo wrote:
PTAL. Another option would be to revert the part of
https://codereview.chromium.org/1178903003 that made
kResolvePossiblyDirectEval
return just one result, and make it take the receiver again, dunno though.
also note that this patch is missing TF support
On 2015/06/24 11:47:57, commit-bot: I haz the power wrote:
CQ is trying da patch. Follow status at
https://chromium-cq-status.appspot.com/patch-status/1202843006/1
Oh dear, I accidentally uploaded a patch on top of this one which was from a
different branch. Will delete and re-cq+ the
Reviewers: Jakob,
Description:
Fix -Werror=sign-compare error with GCC
R=jkumme...@chromium.org
LOG=N
BUG=
Please review this at https://codereview.chromium.org/1202843006/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected files (+1, -1 lines):
M src/frames.cc
Index:
On 2015/06/24 13:30:44, Toon Verwaest wrote:
https://codereview.chromium.org/1202963005/diff/1/src/x64/full-codegen-x64.cc
File src/x64/full-codegen-x64.cc (right):
https://codereview.chromium.org/1202963005/diff/1/src/x64/full-codegen-x64.cc#newcode3064
src/x64/full-codegen-x64.cc:3064: //
New patch adds TF support, in case Michael or someone other TF wizard has
time
to look at it today. Still getting other full-codegen things together.
https://codereview.chromium.org/1202963005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You
On 2015/06/24 15:14:09, Michael Starzinger wrote:
Just to put my thoughts into writing, I am not entirely convinced this is
cleaner than what we had here originally before the cleanup. Also this
uses
one
more bailout point than before. But I don't feel strongly enough to block
this,
and
Added full-codegen implementations for other arches; ptal :)
https://codereview.chromium.org/1202963005/
--
--
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
On 2015/06/24 16:46:50, wingo wrote:
This is a partial fix for
http://code.google.com/p/v8/issues/detail?id=4213
because really we have dedicated errors for this case and should be
signalling
them.
with this patch behavior improves:
d8 function f() { use strict; eval = {} }
(d8):1
Reviewers: arv,
Message:
This is a partial fix for http://code.google.com/p/v8/issues/detail?id=4213
because really we have dedicated errors for this case and should be
signalling
them.
Description:
Fix unexpected token messages in expression classifier
Some tokens need special messages
On 2015/06/24 16:52:46, arv wrote:
LGTM
Thanks; added a message test. Will follow up if I find a way to make it
signal
the right error.
https://codereview.chromium.org/1207743004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received
One nit for a followup perhaps.
https://codereview.chromium.org/1189743003/diff/11/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/1189743003/diff/11/src/preparser.h#newcode3552
src/preparser.h:3552: ReportUnexpectedToken(next);
Nit: will this give the
Michael you are amazing. Thank you!!
https://codereview.chromium.org/1197713004/
--
--
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
Sending half-done review, now to look at rebase. Overall looks pretty
swell but
one question below.
https://codereview.chromium.org/1189743003/diff/60001/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/1189743003/diff/60001/src/preparser.h#newcode3522
https://codereview.chromium.org/1189743003/diff/80001/test/cctest/test-parsing.cc
File test/cctest/test-parsing.cc (right):
https://codereview.chromium.org/1189743003/diff/80001/test/cctest/test-parsing.cc#newcode6608
test/cctest/test-parsing.cc:6608: TEST(DestructuringDuplicateParams) {
Need
LGTM with nit above about rest patterns.
That said :) Is this expected to work for initializers of eagerly-parsed
arrow
functions? I would expect that the literal_count() or the property_count()
of
the initializers would be recorded in the outer scope and not in the arrow
function's
On 2015/06/19 13:55:49, rossberg wrote:
On 2015/06/19 13:45:33, wingo wrote:
On 2015/06/19 13:40:40, rossberg wrote:
https://codereview.chromium.org/1191303002/diff/20001/src/messages.h
File src/messages.h (right):
https://codereview.chromium.org/1191303002/diff/20001/src/messages.h
On 2015/06/19 14:08:38, rossberg wrote:
LGTM
Not for (...x, y) because the (... case reads an identifier and then
does:
[...]
Not for (x, ...y) because that only passes through to
ParseArrowFunctionLiteral
after it has seen the =.
I see. What about about (...pattern) ? :)
Hummm!
On 2015/06/19 13:40:40, rossberg wrote:
https://codereview.chromium.org/1191303002/diff/20001/src/messages.h
File src/messages.h (right):
https://codereview.chromium.org/1191303002/diff/20001/src/messages.h#newcode327
src/messages.h:327: Expected () to start arrow function, but got '%'
On 2015/06/19 13:06:39, rossberg wrote:
On 2015/06/19 12:54:10, wingo wrote:
Previously landed in https://codereview.chromium.org/1187173004/,
reverted
because a layout test did return(); to trigger a devtools behavior,
but
then
matched verbatim on the error, and (); caused a different
On 2015/06/19 14:15:13, wingo wrote:
On 2015/06/19 14:08:38, rossberg wrote:
LGTM
Not for (...x, y) because the (... case reads an identifier and then
does:
[...]
Not for (x, ...y) because that only passes through to
ParseArrowFunctionLiteral
after it has seen the =.
I see. What
Reviewers: rossberg,
Message:
Previously landed in https://codereview.chromium.org/1187173004/, reverted
because a layout test did return(); to trigger a devtools behavior, but
then
matched verbatim on the error, and (); caused a different error after arrow
functions were enabled. This is
Reviewers: rossberg,
Description:
Better error reporting for return();
R=rossb...@chromium.org
BUG=v8:4194
LOG=N
Please review this at https://codereview.chromium.org/1191303002/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected files (+25, -8 lines):
M src/messages.h
M
Reviewers: rossberg,
Description:
Ship arrow functions
R=rossb...@chromium.org
LOG=Y
BUG=v8:2700
Please review this at https://codereview.chromium.org/1187173004/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected files (+1, -1 lines):
M src/flag-definitions.h
Index:
Thanks for the review. Fixed nits, ptal.
https://codereview.chromium.org/1182303004/diff/1/src/macros.py
File src/macros.py (right):
https://codereview.chromium.org/1182303004/diff/1/src/macros.py#newcode163
src/macros.py:163: # itself (it should really use %GetOwnProperty, but
that would be
Reviewers: Jakob,
Description:
Fix -Wsign-compare errors in TF tests under GCC 4.9.2
R=jkumme...@chromium.org
LOG=N
BUG=
Please review this at https://codereview.chromium.org/1191433003/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected files (+5, -5 lines):
M
Reviewers: rossberg,
Message:
WDYT? Given that the previously-specified private symbols were junked
due to
leaking their keys to proxies, it seems OK to re-appropriate the
name private
internally to mean private-own symbols.
Description:
All private symbols are own symbols
On 2015/06/12 12:03:59, wingo wrote:
Patchset 1 is the CL most recently applied. Patchset 2 fixes a nosnap
deserialization test expectation.
Humm, sometimes rollouts are good. I realized I forgot to add the
regression
test to git! Patchset 2 adds the test.
https
Reviewers: rossberg,
Message:
Patchset 1 is the CL most recently applied. Patchset 2 fixes a nosnap
deserialization test expectation.
Description:
Add script context with context-allocated const this
This is a reapplication of https://codereview.chromium.org/117004.
Reviewers: Michael Starzinger, rossberg,
Message:
On 2015/06/12 10:40:16, rossberg wrote:
What has changed?
Patchset 1 is the original patchset. Patchset 2 fixes the gcmole issue, I
think.
Description:
Add script context with context-allocated const this
This is a reapplication of
A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1177903004/ by wi...@igalia.com.
The reason for reverting is: nosnap failure.
https://codereview.chromium.org/117004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
Reviewers: Michael Starzinger, rossberg,
Message:
Created Revert of Add script context with context-allocated const this
Description:
Revert of Add script context with context-allocated const this (patchset
#2
id:20001 of https://codereview.chromium.org/117004/)
Reason for revert:
Reviewers: rossberg,
Message:
An early patch. It works for this, e.g.:
$ out/x64.debug/d8 --print_scopes -e this
global { // (0, 4)
// scope has trivial outer context
// 1 stack slots
// temporary vars:
TEMPORARY .result; // local[0]
// local vars:
DYNAMIC_GLOBAL this; //
}
But
Updated patch works! Now to implement for the eleventy billion
architectures.
https://codereview.chromium.org/1179893002/
--
--
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
On 2015/06/11 16:25:36, wingo wrote:
Updated patch works! Now to implement for the eleventy billion
architectures.
+mstarzinger for the TF patch.
https://codereview.chromium.org/1179893002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You
Reviewers: Dmitry S. Lomov, rossberg,
Description:
Support rest parameters in arrow functions
R=dslo...@chromium.org, rossb...@chromium.org
LOG=Y
BUG=v8:2700
Please review this at https://codereview.chromium.org/1178523002/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected
Fixed to use Spread expression to mark rest parameter presence; ptal :)
https://codereview.chromium.org/1178523002/diff/20001/src/expression-classifier.h
File src/expression-classifier.h (right):
https://codereview.chromium.org/1178523002/diff/20001/src/expression-classifier.h#newcode40
Reviewers: Dmitry S. Lomov,
Description:
Fix copy-pasteo in expression-classifier.h
R=dslo...@chromium.org
LOG=N
BUG=
Please review this at https://codereview.chromium.org/1174543003/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected files (+0, -216 lines):
M
On 2015/06/10 13:21:10, wingo wrote:
On 2015/06/10 11:04:41, Dmitry S. Lomov wrote:
https://codereview.chromium.org/1178523002/diff/20001/src/parser.cc#newcode3811
src/parser.cc:3811: if (!duplicate_loc-IsValid()) {
On 2015/06/10 11:04:41, Dmitry S. Lomov wrote:
Oops, thanks for fixing
On 2015/06/10 13:43:53, rossberg wrote:
https://codereview.chromium.org/1178523002/diff/60001/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/1178523002/diff/60001/src/preparser.h#newcode2266
src/preparser.h:2266: ReportMessageAt(scanner()-peek_location(),
Nit:
On 2015/06/10 15:34:14, arv wrote:
On 2015/06/10 15:24:48, wingo wrote:
On 2015/06/10 15:22:34, wingo wrote:
Fixed nits, PTAL :)
Gaah, it looks like some of the must-be-last error locations are a token
off.
Will fix.
Do you want to fix this in this CL or in a follow up?
Fixed
On 2015/06/10 15:40:01, arv wrote:
LGTM
https://codereview.chromium.org/1178523002/diff/11/test/message/arrow-param-after-rest.out
File test/message/arrow-param-after-rest.out (right):
Looks good!
On 2015/06/10 15:11:26, Dmitry S. Lomov wrote:
WIP - Please take initial look at your leasure.
I am almost done, but some tests still fail, in particular
var f = ({x = 42, y = 15}) = {};
Not sure yet why.
If I had to guess it would be that literal indexes from the parsed {}
Fixed nits, PTAL :)
https://codereview.chromium.org/1178523002/
--
--
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
On 2015/06/10 15:22:34, wingo wrote:
Fixed nits, PTAL :)
Gaah, it looks like some of the must-be-last error locations are a token
off.
Will fix.
https://codereview.chromium.org/1178523002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You
Reviewers: rossberg,
Description:
Stage ES6 arrow functions
R=rossb...@chromium.org
BUG=v8:2700
LOG=Y
Please review this at https://codereview.chromium.org/1166303004/
Base URL: https://chromium.googlesource.com/v8/v8@master
Affected files (+1, -5 lines):
M src/flag-definitions.h
M
Question below. LGTM in either case.
https://codereview.chromium.org/1170153003/diff/20001/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/1170153003/diff/20001/src/preparser.h#newcode1961
src/preparser.h:1961: }
Do we actually want to detect formal parameter
Reviewers: Dmitry Lomov (ooo until Jun 8),
Description:
Speed up ExpressionClassifier::Accumulate
The following changeset introduced a regression on CodeLoad of about 3%:
https://chromium.googlesource.com/v8/v8/+/e73594c7fb3e6b5834b7ddfe78727fb994bab25f
This CL should reduce the regression
Closing this one; I couldn't get a buffer-based thing to go faster. Oh
well :)
https://codereview.chromium.org/1140813008/
--
--
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
On 2015/05/26 12:15:31, Yang wrote:
Andy, you can count yourself lucky that I didn't revert your CL again ;)
Wow, thank you Yang. Coming back from a trip I was a bit terrified to see
what
had happened here; a relief to see that it stuck.
https://codereview.chromium.org/1157993002/
--
--
Late LGTM also. Thank you Michael!
https://codereview.chromium.org/1146063006/
--
--
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
Regarding buffers: there should be some way to use a buffer as a stack.
Like,
whenever you go to assert that something is an expression (or some other
terminal production), you can truncate the buffer back to where it was
when
the
ExpressionClassifier was created. If you need to signal an
Reviewers: rossberg, Yang,
Message:
Created Revert of Reapply Resolve references to this the same way as
normal
variables
Description:
Revert of Reapply Resolve references to this the same way as normal
variables (patchset #2 id:20001 of
https://codereview.chromium.org/1136883006/)
Reason
A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1146733002/ by wi...@igalia.com.
The reason for reverting is: Something is deserializing this declarations
as
Variable::NORMAL and not Variable::THIS
https://codereview.chromium.org/1136123010/.
On 2015/05/19 10:01:51, Igor Sheludko wrote:
This test still fails after https://codereview.chromium.org/1136883006
lgtm, thanks for the test case :) the offending cl has been reverted, so r+
from me to land this one
https://codereview.chromium.org/1136123010/
--
--
v8-dev mailing list
Reviewers: rossberg,
Message:
Round and round we go! Patchset 1 is patch as reverted; PS2 adds a slot to
ScopeInfo for scopes with a this binding so we can know what
Variable::Kind to
use when deserializing this bindings, to fix the bug found in
Another thing that could work would be to write errors into a buffer
instead,
and the buffer doesn't get copied. An ExpressionClassifier would become a
pointer to the start of the buffer, along with a mask of invalid-production
errors seen since the start of the buffer. I guess you'd allocate
Reviewers: Dmitry Lomov (chromium),
Message:
A WIP to fix the code-load regression. Before the offending patch, a
code-load
run locally took 903M instructions with ia32.release, after about 924M
instructions, which matches the measured regression. Simply commenting out
the
nested
On 2015/05/19 16:20:58, wingo wrote:
On 2015/05/19 15:15:41, wingo wrote:
Another thing that could work would be to write errors into a buffer
instead,
and the buffer doesn't get copied. An ExpressionClassifier would
become a
pointer to the start of the buffer, along with a mask
On 2015/05/19 15:15:41, wingo wrote:
Another thing that could work would be to write errors into a buffer
instead,
and the buffer doesn't get copied. An ExpressionClassifier would become a
pointer to the start of the buffer, along with a mask of
invalid-production
errors seen since
1 - 100 of 623 matches
Mail list logo
