This is similar to HashMap::get(key), which returns an Optional, empty
if the index is out of bounds for the vector.
(cherry picked from commit 44798f44ef1c112aa9dbee7abee7ff6a5568c4f4)
The motivation is to allow functions that use FloatExtractor to be
constexpr. Type punning through a union will never work in constexpr.
In practice, bit_cast<>()ing bit fields also does not yet work in clang,
but that's just a bug and it will work eventually (and it does already
work in gcc): https://github.com/llvm/llvm-project/issues/54018
No behavior change.
atan() isn't implemented yet on non-x86, so this isn't super useful yet.
But it does handle a couple corner cases correctly already, and those
are even enough to make all the atan2 tests in Tests/LibC/TestMath.cpp
pass 🙃
With this, sin() and cos() are fairly close to the correct values
for all x. It's neither fast nor very accurate, but much better than
what we had before.
Now that we have fmod(), we can implement some symmetries for
sin() and cos(). The core approximation is still very simplistic,
but now it only has to approximate in [0, Pi/2]. So while its error
is still high, it's no longer unbounded.
This is a pretty naive implementation of exp2() that can be improved
a lot, but hey, it beats the sin() and cos() implementation on non-x86.
It also implements exp(x) as exp2(x * log2(e)), with the same
disclaimer.
Just enough to make it possible to pass a lambda to a constexpr function
taking an AK::Function parameter and have that constexpr function call
the passed-in AK::Function.
The main thing is that bit_cast<>s of pointers aren't ok in constexpr
functions, and neither is placement new. So add a union with stronger
typing for the constexpr case.
The body of the `if (is_constexpr_evaluated())` in
`init_with_callable()` is identical to the `if constexpr` right
after it. But `if constexpr (is_constexpr_evaluated())` always
evaluates `is_constexpr_evaluated()` in a constexpr context, so
this can't just add ` || is_constexpr_evaluated()` to that
`if constexpr`.
These new constexpr functions are for the most part identical to
the same non-constexpr functions, except they drop the `volatile`
qualifier on `this`.
`fetch_add()`, `fetch_sub()`, `load()` have explicit
`is_constant_evaluated()` branches that don't call (non-constexpr)
atomic built-ins. Off the constexpr path, they forward to the
volatile functions.
Previously, it ignored 'start', sorting from the array's
beginning. This caused unintended changes and slower
performance. Fix ensures sorting stays within 'start'
and 'end' indices only.
(cherry picked from commit 356016c626546aeb51722fe9ca5bb6a769bfe762)
This API will always succeed in creating a String representing the
provided number in base-10.
(cherry picked from commit dd419b5a8df3b9a32478c4a8f0ea9f70334214cd;
amended to update the rest of the system. No conflicts though!)
We build KERNEL without floats, so that context switches don't have
to save float registers. As a side effect of that, _Float16 results
in a "_Float16 is not supported on this target" diagnostic.
Having IsFloatingPoint<> be false for the upcoming f16 type but
true for other floating point types seems strange, so just stop
having these concepts in kernel code altogether.
These don't have to worry about the input not being valid UTF-8 and
so can be infallible (and can even return self if no changes needed.)
We use this instead of Infra::to_ascii_{upper,lower}_case in LibWeb.
(cherry picked from commit 073bcfd3866852a4c4bcca2bd131bd65ae53541f)
Returns one Utf8View at a time, using a callback function to identify
code points to split on.
(cherry picked from commit 3f10a5701d9634e47111203b837283bdfc2d8b18)
Before this change, a StringView with a character-data pointer would
never compare as equal to one with a null pointer, even if they were
both length 0. This could happen for example if one is
default-initialized, and the other is created as a substring.
(cherry picked from commit ec5101a1d3cc7bc9068fa4863e16aa482536929a)
First, this isn't actually helpful, as we no longer store 32-bit values
in JsonValue. They are stored as 64-bit values anyways.
But more imporatantly, there was a bug here when trying to coerce an i64
to an i32. All negative values were cast to an i32, without checking if
the value is below NumericLimits<i32>::min.
(cherry picked from commit 7b3b608cafbed8049ac7a34104c66622c1445ffc)
This also makes `Utf8View::trim` significantly faster, since most
strings start and end with ASCII.
(cherry picked from commit 7f3269fb025051c3eb2794b15e785b85b0ce37f3)
And let's at least try to pre-allocate an appropriate amount of
buffer space in the builder instead of appending and growing one
code point at a time.
(cherry picked from commit b6e28ff80779520ccb49e6c15ae1866bbc8713a7)
Also updates a LibWeb text test that used to report the wrong line
number.
(cherry picked from commit 02b50d463b174e5d525c7ab8ce8dd173d550de28;
amended to exclude LineTrackingLexer from KERNEL, since that now use
make<>)
This is necessary for the next commit (and might even help performance
in some very weird cases).
(cherry picked from commit e5f87eb12bdad9dfbf8a825461ac17fdb8457f50;
amended to add a missing include of StdLibExtras.h for move())
You can now build with STYLE_INVALIDATION_DEBUG and get a debug stream
of reasons why style invalidations are happening and where.
I've rewritten this code many times, so instead of throwing it away once
again, I figured we should at least have it behind a flag.
(cherry picked from commit ddbfac38b0074819470766846fca08fd78630eb0;
minorly amended for conflicts in AK/Debug.h.in and
Meta/CMake/all_the_debug_macros.cmake due to us having more debug
macros. Also, downstream got alphabetical order for
STYLE_INVALIDATION_DEBUG wrong.)
(cherry picked from commit 7a17c654d293c4afaf3086dc94e8cd4bceac48b1;
amended to resolve minor conflict in TestUtf16.cpp due to us not
(yet?) having `TEST_CASE(null_view)`. Also amended to make the new
method not call simdutf -- it's now also inefficient, but at least
the inefficient code is now only in one place instead of in several)
This ports the same optimization which was made in
1a46d8df5fc81eb2c320d5c8a5597285d3d8fb3a to this function as well.
(cherry picked from commit 1e8cc97b731871409316c121e637c32806135122)
This takes a byte sequence and converts it to a UTF-8 string with the
replacement character.
(cherry picked from commit 033ea0e7fb0f72338ae95aa0413da838206440bb)
Only take this fast path if the power actually fits in an integer type.
Also, use 64-bit integers in all cases so that the fast path can be
taken more often.
This makes it a compile error to use is<T>() where the input and output
types are known to be the same at compile time.
(cherry picked from commit 82a63e350cb9a67cbd3aa659d909ae9e6599e93f)
