This is especially helpful where we already pass StringView literals
and only compare them with others, e.g. overflow and largest/smallest
unit, in which case there's no need to actually allocate a string.
Previously, LibUnicode would store the values of a keyword as a Vector.
For example, the locale "en-u-ca-abc-def" would have its keyword "ca"
stored as {"abc, "def"}. Then, canonicalization would occur on each of
the elements in that Vector.
This is incorrect because, for example, the keyword value "true" should
only be dropped if that is the entire value. That is, the canonical form
of "en-u-kb-true" is "en-u-kb", but "en-u-kb-abc-true" does not change
for canonicalization. However, we would canonicalize that locale as
"en-u-kb-abc".
This should fix the flaky tests of test-js.
It also fixes the tests when running with the -g flag since the values
will not be garbage collected too soon.
This was one of the first AOs used for Intl, and I misinterpreted the
spec. Rather than removing all extensions, we must only remove Unicode
locale extensions.
Also use LocaleID::to_string() here instead of the heavier canonical
string method, because the locale is already canonical.
These are tested by test262 but the current test262-runner reads the
files in python which automatically converts \r\n to \n.
This meant that we passed the tests while we should not have.
...by replacing it with a ctor that takes the buffer instead, and
handling the allocation failure in ArrayBuffer::create(size_t) by
throwing a RangeError as specified by the spec.
Instead of having a single limit here, which we had to increase once to
work with ASAN enabled, check whether HAS_ADDRESS_SANITIZER is defined
and use 32 KiB, and 16 KiB otherwise (which is what we used previously).
This idea is shamelessly stolen from V8:
b2b44af/src/execution/isolate.cc (L1381-L1387)
It relies on a mapper function to convert each T& to a JS::Value. This
allows us to avoid awkward Vector<T> to MarkedValueList conversion at
the call site.
Our existing implementation did not check the element type of the other
pointer in the constructors and move assignment operators. This meant
that some operations that would require explicit casting on raw pointers
were done implicitly, such as:
- downcasting a base class to a derived class (e.g. `Kernel::Inode` =>
`Kernel::ProcFSDirectoryInode` in Kernel/ProcFS.cpp),
- casting to an unrelated type (e.g. `Promise<bool>` => `Promise<Empty>`
in LibIMAP/Client.cpp)
This, of course, allows gross violations of the type system, and makes
the need to type-check less obvious before downcasting. Luckily, while
adding the `static_ptr_cast`s, only two truly incorrect usages were
found; in the other instances, our casts just needed to be made
explicit.
And also try_create<T> => try_make_ref_counted<T>.
A global "create" was a bit much. The new name matches make<T> better,
which we've used for making single-owner objects since forever.
