Note that only option type=region is really implemented. Other types
will resort to the fallback option. This prototype method will be able
to implement other type options once LibUnicode supports more.
There is notably FIXME notations in this commit regarding Unicode locale
extensions. We are not parsing extensions (or private use extensions) at
all yet.
This bug was discovered via OSS fuzz, it's possible to fall through
to this assert with a char_size == 1, so we need to account for that
in the VERIFY(..).
Repro test case can be found in the OSS fuzz bug:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37296
Added a test to ensure the behavior stays the same.
We now throw on a direct usage of an escaped keywords with a specific
error to make it more clear to the user.
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.
For example, "property.br\u{64}wn" should resolve to "property.brown".
To support this behavior, this commit changes the Token class to hold
both the evaluated identifier name and a view into the original source
for the unevaluated name. There are some contexts in which identifiers
are not allowed to contain Unicode escape sequences; for example, export
statements of the form "export {} from foo.js" forbid escapes in the
identifier "from".
The test file is added to .prettierignore because prettier will replace
all escaped Unicode sequences with their unescaped value.
Unfortunately, this requires a slight divergence in the way the capture
group names are stored. Previously, the generated byte code would simply
store a view into the regex pattern string, so no string copying was
required.
Now, the escape sequences are decoded into a new string, and a vector
of all parsed capture group names are stored in a vector in the parser
result structure. The byte code then stores a view into the
corresponding string in that vector.
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.