Comment #12 on issue 4395 by ad...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
For all arrow functions that aren't immediately executed, we already parse
twice. I would imagine it's uncommon to immediately execute arrows,
Comment #11 on issue 4395 by rossb...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
There is a difference between eager parsing and eager compilation, though.
The trick might work, but it would be a hack for sure. It would
Comment #10 on issue 4395 by wi...@igalia.com: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
[forgot to send this this morning]
How funny! Last time I looked at SpiderMonkey they had to *prevent* lazy
parsing. Funny stuff.
Not sure if
Comment #9 on issue 4395 by ad...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
Here's an alternative, crazy idea: always lazy-compile arrow functions.
When lazy-compiled, everything works fine, since we re-parse the
Comment #8 on issue 4395 by wi...@igalia.com: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
Sadly I think we have to add another visitor then :( Something like the
reindexer, but which just unlinks scopes for VariableProxies in
Issue 4395: assignments in default parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
This issue is now blocking issue v8:2160.
See https://code.google.com/p/v8/issues/detail?id=2160
--
You received this message because you are listed in the owner
or CC fields of this
Comment #7 on issue 4395 by ad...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
To confirm #4, the pattern (LHS of assignment for default parameters) is
properly rewritten, but no rewriting is done to the initializer.
Comment #4 on issue 4395 by wi...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
Adam: The scoping thing is well-known I think. When a comma expression
turns out to be an arrow function parameter list, simple parameters are
Comment #5 on issue 4395 by ad...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
Yeah, I'm digging into the pattern rewriter now. But I'm worried that more
complex examples, such as default values that are functions, will
Comment #2 on issue 4395 by ad...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
Simpler test case that fails:
((a,b=a)=[a,b])(10)
throws a ReferenceError for `a` not being defined. And indeed, because of
the DYNAMIC_GLOBAL,
Updates:
Status: Started
Owner: ad...@chromium.org
Cc: -ad...@chromium.org rossb...@chromium.org
Comment #1 on issue 4395 by ad...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
Looks like it's only in
Comment #3 on issue 4395 by ad...@chromium.org: assignments in default
parameter initializers
https://code.google.com/p/v8/issues/detail?id=4395
This seems to be a very basic design issue with the way arrows are parsed:
we create all the AST before we know we're in a parameter list, so the
12 matches
Mail list logo
