Rename JSMonitorRecordingStatus to JSRecordingStatus. The JSMRS_
prefix becomes JSRS_, accordingly.
Make 'record_' functions return JSRecordingStatus, not bool. 'false'
becomes 'JSRS_STOP'; 'true' becomes 'JSRS_CONTINUE'. Since subsequent
patches will begin to use more than two values (the next assigns
meaning to JSRS_IMACRO), take care to propagate values to callers
accurately.
Define a new recording status, JSRS_ERROR. Return it from recording
functions when appropriate. Check for it at appropriate bottlenecks
in tracer and interpreter.
ABORT_TRACE becomes one of:
. ABORT_TRACE, for when we're simply aborting the recording process
. ABORT_TRACE_ERROR, for aborting due to an error
. ABORT_TRACE_CV, for producing an error message and returning something
other than JSRS_STOP --- some contexts require boolean values.
Conditionally provide an alternative definition for the
JSRecordingStatus type that cannot be converted to 'bool', so that we
can use the C++ compiler to catch improperly converted code.
Use recording function return value for imacro invocation. Eliminate
the JSFRAME_IMACRO_START frame flag. Instead, return JSRS_IMACRO
directly from recording functions.
Terminology:
A "script block" is an object of class Block allocated by the byte
compiler and associated with a script. Script blocks are never
modified, and may be used as a prototype for a "closure block":
A "closure block" is an object of class Block that holds variables
that have been closed over (although we actually leave the variables
on the stack until we leave their dynamic scope). A closure block is
a clone of a script block (its prototype is a script block).
Adjust the meanings of fp->blockChain and fp->scopeChain:
fp->blockChain is always the innermost script block in whose static
scope we're executing.
fp->scopeChain is the current scope chain, including 'call' objects
and closure blocks for those function calls and blocks in whose
static scope we are currently executing, and 'with' objects for with
statements; the chain is typically terminated by a global object.
However, as an optimization, the young end of the chain omits block
objects we have not yet needed to clone.
Closures need fully reified scope chains, so have js_GetScopeChain
reify any closure blocks missing from the young end of fp->scopeChain
by cloning script blocks as needed from fp->blockChain. Thus, if we
never actually close over a particular block, we never place a closure
block for it on fp->scopeChain.
Have JSOP_ENTERBLOCK and JSOP_LEAVEBLOCK always keep fp->blockChain
current. When JSOP_LEAVEBLOCK pops a block from fp->blockChain that
has been cloned on fp->scopeChain, pop fp->scopeChain as well.
Remove the JSFRAME_POP_BLOCKS flag, as it is no longer needed.
Ensure that the JIT won't have to create closure blocks or call
js_PutBlockObject; it can't handle those things yet. Note our current
script block when we begin recording. Abort recording if we leave
that block; we can't tell in advance whether it will need to be "put"
in future trace invocations. Leave trace if we call js_GetScopeChain
while in the static scope of lexical blocks. Remove JIT tests based
on JSFRAME_POP_BLOCKS.
Verify that generators capture the correct value for blockChain.
Add a constructor to JSAutoTempValueRooter for rooting JSObject
pointers.
Terminology:
A "script block" is an object of class Block allocated by the byte
compiler and associated with a script. Script blocks are never
modified, and may be used as a prototype for a "closure block":
A "closure block" is an object of class Block that holds variables
that have been closed over (although we actually leave the variables
on the stack until we leave their dynamic scope). A closure block is
a clone of a script block (its prototype is a script block).
Adjust the meanings of fp->blockChain and fp->scopeChain:
fp->blockChain is always the innermost script block in whose static
scope we're executing.
fp->scopeChain is the current scope chain, including 'call' objects
and closure blocks for those function calls and blocks in whose
static scope we are currently executing, and 'with' objects for with
statements; the chain is typically terminated by a global object.
However, as an optimization, the young end of the chain omits block
objects we have not yet needed to clone.
Closures need fully reified scope chains, so have js_GetScopeChain
reify any closure blocks missing from the young end of fp->scopeChain
by cloning script blocks as needed from fp->blockChain. Thus, if we
never actually close over a particular block, we never place a closure
block for it on fp->scopeChain.
Have JSOP_ENTERBLOCK and JSOP_LEAVEBLOCK always keep fp->blockChain
current. When JSOP_LEAVEBLOCK pops a block from fp->blockChain that
has been cloned on fp->scopeChain, pop fp->scopeChain as well.
Remove the JSFRAME_POP_BLOCKS flag, as it is no longer needed.
Ensure that the JIT won't have to create closure blocks or call
js_PutBlockObject; it can't handle those things yet. Note our current
script block when we begin recording. Abort recording if we leave
that block; we can't tell in advance whether it will need to be "put"
in future trace invocations. Leave trace if we call js_GetScopeChain
while in the static scope of lexical blocks. Remove JIT tests based
on JSFRAME_POP_BLOCKS.
Verify that generators capture the correct value for blockChain.
Add a constructor to JSAutoTempValueRooter for rooting JSObject
pointers.
Terminology:
A "script block" is an object of class Block allocated by the byte
compiler and associated with a script. Script blocks are never
modified, and may be used as a prototype for a "closure block":
A "closure block" is an object of class Block that holds variables
that have been closed over (although we actually leave the variables
on the stack until we leave their dynamic scope). A closure block is
a clone of a script block (its prototype is a script block).
Adjust the meanings of fp->blockChain and fp->scopeChain:
fp->blockChain is always the innermost script block in whose static
scope we're executing.
fp->scopeChain is the current scope chain, including 'call' objects
and closure blocks for those function calls and blocks in whose
static scope we are currently executing, and 'with' objects for with
statements; the chain is typically terminated by a global object.
However, as an optimization, the young end of the chain omits block
objects we have not yet needed to clone.
Closures need fully reified scope chains, so have js_GetScopeChain
reify any closure blocks missing from the young end of fp->scopeChain
by cloning script blocks as needed from fp->blockChain. Thus, if we
never actually close over a particular block, we never place a closure
block for it on fp->scopeChain.
Have JSOP_ENTERBLOCK and JSOP_LEAVEBLOCK always keep fp->blockChain
current. When JSOP_LEAVEBLOCK pops a block from fp->blockChain that
has been cloned on fp->scopeChain, pop fp->scopeChain as well.
Remove the JSFRAME_POP_BLOCKS flag, as it is no longer needed.
Ensure that the JIT won't have to create closure blocks or call
js_PutBlockObject; it can't handle those things yet. Note our current
script block when we begin recording. Abort recording if we leave
that block; we can't tell in advance whether it will need to be "put"
in future trace invocations. Abort recording if we call
js_GetScopeChain while in the static scope of lexical blocks. Remove
JIT tests based on JSFRAME_POP_BLOCKS.
Verify that generators capture the correct value for blockChain.
Add a constructor to JSAutoTempValueRooter for rooting JSObject
pointers.
Delete jsstddef.h, since its only remaining purpose is to make certain
Win16-specific definitions; we don't support Win16 any more. In
particular, we can just subtract pointers now, so the PTRDIFF macro is
unnecessary noise.
Most places get stddef.h via jstypes.h or some other header, so we can
just delete #inclusions of jstddef.h. The exception is jskwgen.h, so
there we explicitly include <stddef.h> instead.
