Only create an iterator for coercible types in OP_ITERATOR, and then
detect the lack of a real iterator in OP_NEXTITER.
Thus we don't need to allocate and push an empty iterator object for
these cases.
The temporary array we use for sorting cannot be seen by the GC, and that
violates the constraint that all js_Value values must always be reachable
from the stack or global environment.
Temporarily turning off the GC will let us use the temporary array for
fast sorting using qsort(), without tripping over this violation.
Don't distinguish lax mode code by pushing the global object.
Always push undefined and let the calling code promote an undefined
this to the global object instead.
As a side effect when changing to using regular integers (and avoid the
nightmare of mixing signed and unsigned) we accidentally allowed negative
array lengths.
Make sure to make a copy of the source pattern string.
A case we missed when adding short and memory strings to the runtime.
The code assumed all strings passed to it were either literal or interned.
Due to our slightly icky struct layout, some versions of gcc barf and
generate crashing code when using strcpy and memcpy. I suspect gcc tries
to do some weird optimizations that fail because we intentionally
overwrite the 'pad' data in the js_Value struct for short strings.
Revert 'add context and flag argument to js_newstate' commit.
The context argument just adds clutter. The flag which was intended
for JS_DEBUG and/or JS_STRICT shouldn't be necessary.
js_newcfunction and js_newcconstructor need an extra argument, the
name of the function to use in stack traces.
Any coercion between types may overwrite the stack slot with the coerced
value. This is usually not a problem, but if you need to preserve the
original value, you should copy it to another stack slot before running
any functions that may coerce the type (anything involving ToPrimitive).
This change lets us avoid interning the result of toString().
If we later add short strings (embedded in js_Value and js_Property
structs) then we can also avoid creating a garbage collected string or
interning the result of js_tostring on a number.
Separate literal/interned and garbage collected string types in js_Value.
js_pushintern/js_tointern are convenience functions to push/pop strings and
automatically intern them (so that the string pointers are guaranteed to be
stable).
js_pushliteral should push stable strings (either interned or actual literals).
js_pushstring will copy the string into garbage collected memory.
The pointer returned by js_tostring is guaranteed to be stable only for as long as
the stack slot it came from remains untouched.
Some uses will always cause a string to be interned:
* Using it as a property name.
* Wrapping it in a new String() object.
* Strings returned by toString().
ToPrimitive must not clobber the stack, so the result has to be unrooted.
* Numbers converted to strings (by js_tostring)
Likewise, we have nowhere to store the temporary string here.
Passing in a scratch buffer to js_tostring could help this problem.
Mostly an issue with array accesses (OP_GETPROP, etc) so an auxiliary
function and we don't have to clutter the API needlessly.
Add a separate js_loadeval for "eval code" scripts, and let
js_do/loadstring create "global code" scripts.
js_newscript called with the NULL scope is equivalent to 'eval code'.
js_newscript called with the J->GE scape is equivalent to 'global code'.
js_newfunction is created with the lexical scope, i.e. 'function code'.
