On 2015/05/11 16:53:21, wingo wrote:
On 2015/05/11 15:34:25, caitp wrote:
> 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.
Excuse my density, I still don't understand. By "lazy parsing" do you
mean
that
you get errors with the preparser or later when the full parser runs? I
was
thinking that it would actually be impossible to get to the point where
the
full
parser runs lazily because the preparser should have generated an early
error.
There are two ways to parse an arrow function: to reinterpret a comma
expression
as formals and proceed from there, either with the preparser or the full
parser,
or lazily with the full parser, which knows that it is looking for a
formal
parameter list because the preparser has already identified the
expression as
an
arrow function. But to get to that point you have to have already checked
that
the arrow function parameters are valid with the preparser, which should
not
be
the case if there are initializers.
Another question would be how this relates to arrow functions. If arrow
functions are staged first, would it be necessary to support optional
arguments
of arrow function parameters in order to stage optional arguments? Note
that
this might be quite a pain for the reasons I described in the previous
message.
I will see what I can do to enable rest arguments with arrow functions, as
Dmitry's work should make that possible now.
The preparser logs locations to be lazily parsed, we then parse (lazily)
with
the full parser, with a really weird (and incorrect) scope tree, at which
point
ParseFormalParameterList is used on a scope which is not a function scope.
That's what I'm talking about when I'm saying lazy parsing.
I agree that it's going to be a pain to get optional arguments and
destructuring
working in pre-parsed arrow functions without performance regressions, but
what
can you do?
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.
