The current implementation of step 2a sort of manually implemented GetV
with a ToObject + Get combo. But in the call to Get, the receiver wasn't
the correct object. So when invoking toJSON, the receiver was an Object
type rather than a BigInt.
This also adds spec comments to SerializeJSONProperty.
This partially reverts commit a962ee020a.
When the sticky bit is set, the global bit should basically be ignored
except by external callers who want their own special behavior. For
example, RegExp.prototype [ @@match ] will use the global flag to
accumulate consecutive matches. But on the first failure, the regex
loop should break.
Since the spec does not fully define the entry points of modules what
this means is kind of unclear. But it does work in most cases and can
be useful. We do print out a warning just to clarify why there could be
strange things.
It seems the stack search does not find all functions because they are
kept in variants and other structs. This meant some function could be
cleaned up while we were evaluating a class meaning it would fail/crash
when attempting to run the functions.
This feature had bitrotted somewhat and would trigger errors because
PrimitiveStrings were "destroyed" but because of this mode they were not
removed from the string cache. Even fixing that case running test-js
with the options still failed in more places.
LibRegex already implements this loop in a more performant way, so all
LibJS has to do here is to return things in the right shape, and not
loop over the input string.
Previously this was a quadratic operation on string length, which lead
to crazy execution times on failing regexps - now it's nice and fast :^)
Note that a Regex test has to be updated to remove the stateful flag as
it repeats matching on multiple strings.
This is a normative change in the ECMA-262 spec:
ca53334
Note that this also fixes a few errors where we errantly converted the
stored time value to local time.
The spec defines a StringToBigInt AO which allows for converting binary,
octal, decimal, and hexadecimal strings to a BigInt. Our conversion was
only allowing for decimal strings.
Two of our most frequently allocated objects are Shape (88 bytes)
and DeclarativeEnvironment (80 bytes). Putting these into 128-byte
cells was quite wasteful, so let's add a more suitable allocator
for them.
We don't need to support more than 2^32 object properties anyway, so
there's no point in using 64-bit property counts.
This small reduction in memory usage makes test-js run ~10% faster on
x86_64 locally.
Using an Optional was extremely wasteful for function objects that don't
even have a bytecode executable.
This allows ECMAScriptFunctionObject to fit in a smaller size class.
