All regex flags supported by LibJS currently correspond to a LibRegex
option, but this is not the case for the RegExp.prototype.hasIndices
proposal, which is handled entirely in RegExpBuiltinExec. Remove the
flag mapping to prepare for this. This incurs a bit of an optimization
loss in the flag getters, as we now do a substring search, but we can
revisit the getter implementation if it becomes an issue.
Our RegExpBuiltinExec implementation differed from the spec in some
areas such as handling of the sticky/global flags and updating the
lastIndex property.
This allows passing an existing RegExp object (or an object that is
sufficiently like a RegExp object) as the "pattern" argument of the
RegExp constructor.
As an abstraction, RegExpExec should not assume that the RegExp object
being used is "this" object. Instead, it should only interact with the
provided object.
This prepares for some methods, such as @@split, which invoke RegExpExec
with a secondary RegExp object.
Not all of the TypedArray prototype methods and accessors require
detached buffer validation (only the ones who call ValidateTypedArray)
so this behaviour was split from typed_array_from and the usage was
updated per the spec in each location.
create_from() casts the value to a 64 bit integer and then creates two
words from it, which is not necessary if we only pass values to it that
fit into a single word (32 bit integer).
Also make them use UnsignedBigInteger as the previously missing SBI
divided_by() overload is now implemented.
Previously, in LibGFX's `Point` class, calculated distances were passed
to the integer `abs` function, even if the stored type was a float. This
caused the value to unexpectedly be truncated. Luckily, this API was not
used with floating point types, but that can change in the future, so
why not fix it now :^)
Since we are in C++, we can use function overloading to make things
easy, and to automatically use the right version.
This is even better than the LibC/LibM functions, as using a bit of
hackery, they are able to be constant-evaluated. They use compiler
intrinsics, so they do not depend on external code and the compiler can
emit the most optimized code by default.
Since we aren't using the C++ standard library's trick of importing
everything into the `AK` namespace, this `abs` function cannot be
exported to the global namespace, as the names would clash.
