https://codereview.chromium.org/1127063003/diff/60001/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/1127063003/diff/60001/src/parser.cc#newcode1153
src/parser.cc:1153: ParseFormalParameter(scope, &error_locs, nullptr,
nullptr, has_rest,
On 2015/05/11 15:00:48, wingo wrote:
nit: would be easier to read with named variables for these nullptrs
Acknowledged.
https://codereview.chromium.org/1127063003/diff/60001/src/parser.cc#newcode3546
src/parser.cc:3546: // If hasParameterExpressions for the function is
true, each parameter is
On 2015/05/11 15:00:48, wingo wrote:
has_initializers I guess? I know hasParameterExpressions is the spec
language;
is has_initializers the same?
HasParameterExpressions is also true for Object binding patterns with
computed property keys, so the language will have to change eventually
https://codereview.chromium.org/1127063003/diff/60001/src/parser.cc#newcode3574
src/parser.cc:3574: DCHECK(ok);
On 2015/05/11 15:00:48, wingo wrote:
Seems that Declare can only fail for a var redeclaration, which is
impossible
here, OK. Still, a comment would save the reader some time :)
Acknowledged.
https://codereview.chromium.org/1127063003/diff/60001/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/1127063003/diff/60001/src/preparser.h#newcode3541
src/preparser.h:3541: DCHECK(scope_->is_function_scope());
On 2015/05/11 15:00:48, wingo wrote:
On 2015/05/09 20:57:22, caitp wrote:
> Apparently this is a problem for lazy-parsed arrow functions :(
There has got
to
> be a better way
So only lazy-parsed arrow functions will have a chance to have
initializer
expressions AFAIU -- is that right? I mean, otherwise we don't know
that it's
an initializer and you haven't modified
ParseArrowFunctionFormalParameters to
handle initializers. That is going to be horrific by the way --
you'll be
lifting expressions parsed in one function to another. There's still
some state
being allocated in the parser (literal counts, handler indices,
expected
property counts) that will need to be rewritten for initializers
lifted to inner
functions. In my mind the right way to do that is to move to a
post-pass; for
that reason it seems that optional argument initializers are going to
be quite a
challenge. Dunno.
So that said it should be impossible to get to a lazily parsed arrow
function
with default initializers with the current code. The preparser should
have
already discounted the possibility of the "formals" of the arrow
function being
valid.
The issue with lazy-parsing is that the scope doesn't seem to be a
function/arrow scope during lazy parsing --- so the DCHECK fails, and in
release builds we're potentially declaring things in the wrong scope.
Right now, arrow functions never have valid destructuring of any kind,
and that will take more work to support. But we want this DCHECK not to
fail, so we might need to encode some extra info when lazily parsing
these.
https://codereview.chromium.org/1127063003/diff/60001/src/scopes.cc
File src/scopes.cc (right):
https://codereview.chromium.org/1127063003/diff/60001/src/scopes.cc#newcode468
src/scopes.cc:468: param_positions_.Add(pos, zone());
On 2015/05/11 15:02:51, wingo wrote:
Don't we require already that parameters are declared left-to-right?
In that
case the "pos" argument is unneeded. Just a thought.
It's needed because they end up as lexical declarations, which require a
position. The hole-checking logic uses it too, so it needs to be
accurate
https://codereview.chromium.org/1127063003/
--
--
v8-dev mailing list
[email protected]
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, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
