Problem:
- Type and size information is known at compile-time, but computations
are being performed using run-time parameters.
Solution:
- Move function arguments to be template arguments.
- Convert to `consteval` where possible.
- Decorate functions with `constexpr` which are used in both run-time
and compile-time contexts.
Problem:
- Global variables (and variable templates) defined in header files
need to be decorated `inline` to avoid multiple definition issues.
Solution:
- Put back the `inline` keyword which was erroneously removed.
Problem:
- `constexpr` functions are additionally decorated with `inline`
keyword. This is redundant since `constexpr` implies `inline`.
Solution:
- Remove redundancies.
PR #6376 made IntrusiveList capable of holding RefPtr<T>, etc. however
there was a latent bug where take_first() / take_last() would fail to
compile because they weren't being converted to their container type.
Problem:
- Post-increment of loop index.
- `const` variables are not marked `const`.
- Incorrect type for loop index.
Solution:
- Pre-increment loop index.
- Mark all possible variables `const`.
- Corret type for loop index.
Problem:
- Hex digit decoding is not `constexpr`, but can be.
Solution:
- Move the body of the function to the header and decorate with
`constexpr`.
- Provide tests for run-time and compile-time evaluation.
Some of the expected values in test-math were wrong, which caused some
tests to fail.
The updated values were generated by Python's math library, and rounded
to 6 decimals places:
>>> import math
>>> round(math.exp(20.99), 6)
1305693298.670892
Examples of failure outputs:
FAIL: ../Userland/Tests/LibM/test-math.cpp:98:
EXPECT_APPROXIMATE(exp(v.x), v.exp) failed with
lhs=1305693298.670892, rhs=1304956710.432034, (lhs-rhs)=736588.238857
FAIL: ../Userland/Tests/LibM/test-math.cpp:99:
EXPECT_APPROXIMATE(sinh(v.x), v.sinh) failed with
lhs=652846649.335446, rhs=652478355.216017, (lhs-rhs)=368294.119428
FAIL: ../Userland/Tests/LibM/test-math.cpp💯
EXPECT_APPROXIMATE(cosh(v.x), v.cosh) failed with
lhs=652846649.335446, rhs=652478355.216017, (lhs-rhs)=368294.119429
We had an unusual optimization in AK::StringView where constructing
a StringView from a String would cause it to remember the internal
StringImpl pointer of the String.
This was used to make constructing a String from a StringView fast
and copy-free.
I tried removing this optimization and indeed we started seeing a
ton of allocation traffic. However, all of it was due to a silly
pattern where functions would take a StringView and then go on
to create a String from it.
I've gone through most of the code and updated those functions to
simply take a String directly instead, which now makes this
optimization unnecessary, and indeed a source of bloat instead.
So, let's get rid of it and make StringView a little smaller. :^)
Previously this would create new to_lowercase()'d strings from the
needle and the haystack. This generated a huge amount of malloc
traffic in some programs.
This should allow creating intrusive lists that have smart pointers,
while remaining free (compared to the impl before this commit) when
holding raw pointers :^)
As a sidenote, this also adds a `RawPtr<T>` type, which is just
equivalent to `T*`.
Note that this does not actually use such functionality, but is only
expected to pave the way for #6369, to replace NonnullRefPtrVector<T>
with intrusive lists.
As it is with zero-cost things, this makes the interface a bit less nice
by requiring the type name of what an `IntrusiveListNode` holds (and
optionally its container, if not RawPtr), and also requiring the type of
the container (normally `RawPtr`) on the `IntrusiveList` instance.
This warning informs of float-to-double conversions. The best solution
seems to be to do math *either* in 32-bit *or* in 64-bit, and only to
cross over when absolutely necessary.
Floating point numbers are casted to i64 and passed to the integer
formatting logic, and the floating point portion of the number is
handled separately. However, casting to i64 when the number is between
-1.0 and 0.0 produces 0, so the sign would be lost. This commit fixes
that by using put_u64 instead, which allows us to manually provide the
is_negative flag.
The find_last_of implementations were breaking out of the search loop
too early for single-character string views. This caused a crash in
CookieJar setting a cookie on google.com - CookieJar::default_path knew
there was at least one "/" in a string view, but find_last_of returned
nullopt, so dereferencing the optional caused a crash.
Fixes#6273
This container is similar to the RedBlackTree container, but instead of
transparently allocating tree nodes on insertion and freeing on removal
this container piggybacks on intrusive node fields in the stored class
This container is based on a balanced binary search tree, and as such
allows for O(logn) worst-case insertion, removal, and search, as well
as O(n) sorted iteration.
If the prefix path is just a slash the LexicalPath was removing too many
characters. Now only remove an extra character if the prefix is not just
the root path.
This commit makes the user-facing StdLibExtras templates and utilities
arguably more nice-looking by removing the need to reach into the
wrapper structs generated by them to get the value/type needed.
The C++ standard library had to invent `_v` and `_t` variants (likely
because of backwards compat), but we don't need to cater to any codebase
except our own, so might as well have good things for free. :^)
This is a pretty naive implementation that works well. The precision
parameter is interpreted as "maximum precision" instead of "minimum
precision", which in my opinion is the most useful interpretation.
The old approach was more complex and also had a very bad edge case
with lots of collisions. This approach eliminates that possiblility.
It also makes both reading and writing lookups a little bit faster.
Almost a year after first working on this, it's finally done: an
implementation of Promises for LibJS! :^)
The core functionality is working and closely following the spec [1].
I mostly took the pseudo code and transformed it into C++ - if you read
and understand it, you will know how the spec implements Promises; and
if you read the spec first, the code will look very familiar.
Implemented functions are:
- Promise() constructor
- Promise.prototype.then()
- Promise.prototype.catch()
- Promise.prototype.finally()
- Promise.resolve()
- Promise.reject()
For the tests I added a new function to test-js's global object,
runQueuedPromiseJobs(), which calls vm.run_queued_promise_jobs().
By design, queued jobs normally only run after the script was fully
executed, making it improssible to test handlers in individual test()
calls by default [2].
Subsequent commits include integrations into LibWeb and js(1) -
pretty-printing, running queued promise jobs when necessary.
This has an unusual amount of dbgln() statements, all hidden behind the
PROMISE_DEBUG flag - I'm leaving them in for now as they've been very
useful while debugging this, things can get quite complex with so many
asynchronously executed functions.
I've not extensively explored use of these APIs for promise-based
functionality in LibWeb (fetch(), Notification.requestPermission()
etc.), but we'll get there in due time.
[1]: https://tc39.es/ecma262/#sec-promise-objects
[2]: https://tc39.es/ecma262/#sec-jobs-and-job-queues
