https://codereview.chromium.org/943543002/diff/320001/src/parser.cc
File src/parser.cc (right):
https://codereview.chromium.org/943543002/diff/320001/src/parser.cc#newcode2039
src/parser.cc:2039: proxy->var()->set_initializer_position(pos);
On 2015/02/25 13:25:03, marja wrote:
On 2015/02/25 13:17:27, rossberg wrote:
> On 2015/02/24 18:05:40, marja wrote:
> > On 2015/02/24 15:52:40, rossberg wrote:
> > > I'm surprised that this isn't a problem, since 'pos' doesn't
seem to point
> at
> > > the right position.
> >
> > This isn't the problem for the
> >
> > class C extends C { }
> >
> > case, because the relevant declaration is done by
ParseClassLiteral, not
this
> > function. (Both ParseClassDeclaration and ParseClassLiteral
declare C, but
the
> > stuff inside the class resolves to what ParseClassLiteral
declared.)
> >
> > IOW, I didn't see a place where this position set here would
matter, so I
> didn't
> > change it.
>
> I see, because it is immediately shadowed in the class-expr on the
RHS.
Subtle.
>
> I'd still prefer the position on the let-variable to be consistent
with other
> let-bindings. I.e., just set it to position().
Okay, did that. So here position() is at the end of the class body...
first I
thought that it wouldn't make sense, and we'd want to set the position
to the
same as the other C variable's position (i.e., after "class C extends
Foo"), but
maybe that's not true. At least position() is less wrong here than
pos.
Why, the outer C is a completely separate variable -- its position
should be exactly what you'd get if you were writing the above
desugaring
let C = class C {...};
manually.
https://codereview.chromium.org/943543002/
--
--
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.
