We always pass NULL as the |pn1| argument to js::Parser::parenExpr; remove
it. We pass NULL for the |genexp| argument in all but one case; give it a
default value. This allows almost all calls to pass no arguments.
We always pass a freshly allocated PN_UNARY node as |generatorExpr|'s first
argument, and never refer to the node again in the caller; move the
allocation into |generatorExpr| itself. This makes |generatorExpr| a
function that takes an expression |E| and returns the immediate application
of a generator function which consists of the nested loops and conditionals
given by the comprehension tail, with a |yield E| at the center.
.
. attachment 493930 - SH4: use non-numeric type for Register & move auto-generated code-generator back to a separated file.
.
Bug 599251 introduced the non-numeric Register type. This back-end doesn't use it yet. It should. See the i386/X64 back-ends for examples.
--HG--
extra : convert_revision : eb3a73807a9c8b2cafe10908710f9cb2467d090d
.
. attachment 485873 - fix asserts so we can compile
.
Bug 599251 introduced the non-numeric Register type. This back-end doesn't use it yet. It should. See the i386/X64 back-ends for examples.
--HG--
extra : convert_revision : b681599a542687e6a9779227f2f21a86b69ee2a9
Never emit bytecode for expression statements consisting of a single string
literal. Complain about them as useless code only if they are not part of a
Directive Prologue. The comments in recognizeDirectivePrologue explain the
details.
Fix bad names of directive-prologue-related parse node member functions.
It turns out that the careful effort RecycleTree and NewOrRecycledNode make
to disassemble the recycled tree lazily is wasted: every recycling call
ends up calling UnlinkFunctionBoxes and walking the entire parse node tree
to fix up funbox and method links. There's no locality; you might as well
queue up the parse nodes while you're at it. And the stack doesn't stay
shallow.
This patch replaces the (very clever) lazy recycling with eager recycling,
using a work stack chained through the nodes themselves to avoid creating
deep C++ stacks when recycling deep parse trees. We put off cleaning up the
method lists and funbox tree until just before function analysis, at which
point we do so in a single linear pass. Putting this off to the end avoids
quadratic behavior, as noted in the comments.
The patch localizes the process of adding nodes to the free list in a
single function, ensuring that we don't recycle used/defn nodes. It also
poisons newly freed nodes.
The patch also more clearly distinguishes between function nodes that have
been fully deleted, and function nodes that have been mutated (by
js_FoldConstants) into other kinds of nodes. See the comments before
Parser::cleanFunctionList.
I believe the patch also improves the care with which we handle nodes that
cannot be recycled immediately (those that appear in JSAtomLists, or are
referred to by JSFunctionBoxes). In some cases, those nodes may be picked
up and fiddled with later, so it is important that they not refer to nodes
around them that did get recycled.
Proper function recycling may mean eliminating the tree context's entire
function list; it's misleading to pass in the function list, rather than
side-effecting the tc in place.
Let analyzeFunctions take care of testing whether we have any functions to
analyze, instead of making each caller do it. In the next patch in the
series, we won't know whether the function list is really clear or not in
the callers anyway.
Avoid passing tcflags around by non-const reference; SpiderMonkey style is
to use pointers for parameters the callee may mutate, to make call sites
more evidently potential mutations.