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.
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.
