On 2015/03/31 12:28:40, caitp wrote:
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
Let us have special intrinsics %_CallWithSpread and %_ConstructWithSpread
instead of flags on a general CallRuntime node (see
DefaultConstructorCallSuper
for inspiration).
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.
