thanks for review!
(arv, more comments?)
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: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.
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.
