The PluralCategory enum is currently generated for plural rules. Instead
of generating it, this moves the enum to the public LibUnicode header.
While it was nice to auto-discover these values, they are well defined
by TR-35, and we will need their values from within the number format
code generator (which can't rely on the plural rules generator having
run yet). Further, number format will require additional values in the
enum that plural rules doesn't know about.
The JS::Intl enum was added when implementing the PluralRules
constructor. Now that LibUnicode has a plural rules implementation,
replace the JS::Intl enum with the analagous Unicode enum.
This is a manual but clean revert of all commits from #12595.
Adding a partial implementation of the resizable ArrayBuffer proposal
without implementing all the updates to TypedArray infrastructure that
is also covered by the spec introduced a bunch of crashes, so we
decided to revert it for now until a full implementation is completed.
This commit has no behavior changes.
In particular, this does not fix any of the wrong uses of the previous
default parameter (which used to be 'false', meaning "only replace the
first occurence in the string"). It simply replaces the default uses by
String::replace(..., ReplaceMode::FirstOnly), leaving them incorrect.
This aligns it with the spec again, it was clarified that the additional
range check before ArrayCreate is intentional:
https://github.com/tc39/proposal-change-array-by-copy/issues/94
Also cast the final variable to an u64 instead of size_t after we have
determined that it is safe to do so, as that's what Array::create()
takes now.
This doesn't matter per se as the value is immediately validated to be
in the 0 to 2^32 - 1 range, but it avoids having to cast a number that
potentially doesn't fit into a size_t into one at the call site. More
often than not, array-like lengths are only validated to be <= 2^52 - 1,
i.e. MAX_SAFE_INTEGER.
This is fully backwards compatible with existing code as a size_t always
fits into an u64, but an u64 might not always fit into a size_t.
This also allows constructing from other integral types like u64, which
would have been ambiguous before (at least on i686):
```
error: call of overloaded 'Value(u64&)' is ambiguous
note: candidate: 'JS::Value::Value(i32)'
175 | explicit Value(i32 value)
| ^~~~~
note: candidate: 'JS::Value::Value(unsigned int)'
164 | explicit Value(unsigned value)
| ^~~~~
note: candidate: 'JS::Value::Value(long unsigned int)'
153 | explicit Value(unsigned long value)
| ^~~~~
note: candidate: 'JS::Value::Value(double)'
141 | explicit Value(double value)
| ^~~~~
```
The implementation no longer matches the spec text, but I believe that's
a bug anyway. No point in allowing array lengths up to 2^53 - 1 when the
ArrayCreate AO rejects anything above 2^32 - 1.
