On 2015/03/31 10:09:43, Dmitry Lomov (chromium) wrote:
My biggest concern is IsSuperFlag on CallRuntime node.
Can you also provide a high-level explanation of desugaring, i.e. what:
f(x,y,...args);
new f(x,y,...args)
super(x,y,...args)
desugar into in the AST
f(x, y, ...args) -> ReflectApply(f, undefined, SpreadArguments([x, y],
SpreadIterable(args))
new f(x, y, ...args) -> ReflectConstruct(f, SpreadArguments([x, y],
SpreadIterable(args))
super(x, y, ...args) -> this =
ReflectConstruct(GetPrototype(%CurrentFunction%),
SpreadArguments([x, y], SpreadIterable(args)), %NewTarget%)
https://codereview.chromium.org/938443002/diff/280001/src/compiler/ast-graph-builder.cc
File src/compiler/ast-graph-builder.cc (right):
https://codereview.chromium.org/938443002/diff/280001/src/compiler/ast-graph-builder.cc#newcode2422
src/compiler/ast-graph-builder.cc:2422: Visit(expr->expression());
Bailout instead of visiting silently
https://codereview.chromium.org/938443002/diff/280001/src/full-codegen.h
File src/full-codegen.h (right):
https://codereview.chromium.org/938443002/diff/280001/src/full-codegen.h#newcode375
src/full-codegen.h:375: if (allow_super && expr->IsSuperReference()) {
Do not do this.
Instead, call EmitLoadSuperConstructor() explicitly.
Meaning of 'super' is different in different contexts.
https://codereview.chromium.org/938443002/diff/280001/src/hydrogen.cc
File src/hydrogen.cc (right):
https://codereview.chromium.org/938443002/diff/280001/src/hydrogen.cc#newcode11055
src/hydrogen.cc:11055: Visit(expr->expression());
Bailout instead of visiting.
https://codereview.chromium.org/938443002/diff/280001/src/x64/full-codegen-x64.cc
File src/x64/full-codegen-x64.cc (right):
https://codereview.chromium.org/938443002/diff/280001/src/x64/full-codegen-x64.cc#newcode4616
src/x64/full-codegen-x64.cc:4616: if (expr->IsSuperCall()) {
On 2015/03/30 22:38:12, caitp wrote:
> On 2015/03/30 22:19:49, arv wrote:
> > This is a bit strange/hacky. I assume this comes from
> >
> > super(...args)
> >
> > which we desugar to
> >
> > %_ReflectConstruct(args, new.target)
> >
> > ?
>
> it's kind of a hack, yeah... but, without it, `this` binding doesn't get
> initialized for supercalls with spread
IsSuperCall flag on CallRuntime node is super-hacky. Can we have a
different
node for spread calls?
It's hacky --- but, having another node would have to do almost identical
work
to CallRuntime, and would be used very little. If that seems worthwhile,
then
that can be done instead
The reason this is done is 2 things: ordinarily, CallRuntime will not be
able to
deal with `super()` as a function (because visiting that node throws, so
EmitLoadSuperConstructor() is needed instead of just visiting the node).
Secondly, initializing the `this` binding is also needed for super calls. A
flag
seemed like the best ay to do this while not rewriting all the relevant
CallRuntime code
https://codereview.chromium.org/938443002/
--
--
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.
