There is notably FIXME notations in this commit regarding Unicode locale
extensions. We are not parsing extensions (or private use extensions) at
all yet.
These should all have a name with an empty string. Not only does test262
verify this, but it also verifies that (for the executor) the name
property is defined after the length property.
PerformPromiseAll, PerformPromiseAny, PerformPromiseAllSettled, etc, all
have very similar iteration loops. To avoid duplicating this rather
large block of code, extract the common functionality into a separate
method.
The element-resolving functions on the Promise constructor are all very
similar. To prepare for more of these functions to be implemented, break
out common parts into a base class.
RegExp.prototype.compile will require invoking RegExpInitialize on an
already-existing RegExpObject. Break up RegExpCreate into RegExpAlloc
and RegExpInitialize to support this.
Instead of constructing a String and converting that to a PropertyName
on the fly, we can just leverage CommonPropertyNames, add a couple more
and directly pass ready-to-use PropertyNames with pre-allocated Strings.
Combining these into one list helps reduce the size of MatchState, and
as a result, reduces the amount of memory consumed during execution of
very large regex matches.
Doing this also allows us to remove a few regex byte code instructions:
ClearNamedCaptureGroup, SaveLeftNamedCaptureGroup, and NamedReference.
Named groups now behave the same as unnamed groups for these operations.
Note that SaveRightNamedCaptureGroup still exists to cache the matched
group name.
This also removes the recursion level from the MatchState, as it can
exist as a local variable in Matcher::execute instead.
The check for stack space in VM from push_execution_context has been
moved to a method on VM called did_reach_stack_space_limit. This
allows us to check the stack size in other places besides
push_execution_context.
We can now verify that we have enough space on the stack before calling
flatten_into_array to ensure that we don't cause a stack overflow error
when calling the function with a large depth.
