Add a basic clang-tidy configuration that enables checks from the
following categories:
- bugprone
- cert
- clang-analyzer
- concurrency
- misc
- performance
- portability
- readability
The noisiest rules that have conflicts with the project style guide or
accepted practices have been turned off.
There's absolutely more work to be done here before we could consider
setting any of these warnings as errors and enforcing them in CI, but
committing a project clang-tidy configuration should help the rules
become more visible and let other contributors take a crack at tweaking
rules and/or finding possible bugs.
Sadly the cpp-core-guidelines and modernize categories are very, very
noisy. If we want to enable rules from these categories, they would need
to be on a rule by rule basis.
Serenity defines a protected range of memory that must not be mmapped,
and is apparently reserved for kernel tasks. In this case, the protected
range is anything below 0x800000.
However, in its default setting, binutils chooses the memory address
0x400000 as the mapping address for executables that do not have PIE
enabled, resulting in mmap being unable to map the file unless the load
address has been overwritten at link time or if it's a PIE.
To mitigate this, move the default base address somewhere outside of
that range (and preferably not anywhere close near the beginning of the
useable virtual memory space, to avoid running into it during sequential
allocations).
C++17 introduced aligned versions of `new` and `delete`, which are
automatically called by the compiler when allocating over-aligned
objects. As with the regular allocator functions, these are generally
thin wrappers around LibC.
We did not have support for aligned allocations in LibC, so this was not
possible. While libstdc++ has a fallback implementation, libc++ does
not, so the aligned allocation function was disabled internally. This
made building the LLVM port with Clang impossible.
Note that while the Microsoft docs say that aligned_malloc and
_aligned_free are declared in `malloc.h`, libc++ doesn't #include that
file, but instead relies on the definition coming from `stdlib.h`.
Therefore, I chose to declare it in that file instead of creating a new
LibC header.
I chose not to implement the more Unix-y `memalign`, `posix_memalign`,
or the C11 `aligned_alloc`, because that would require us to
significantly alter the memory allocator's internals. See the comment in
malloc.cpp.
Previously if code attempted to use the format specifier somewhere
(Ex: "%#4.3Lg"), the specifier would get dropped and we would just
print "g" instead of any value. Now at least we print a value.
I wanted to do this for a long time. The guts of Promise are pretty
complex, and it's easier to understand with the spec right next to it.
Also found a couple of issues along the way :^)
Render the window switcher with the same background and shadow as other
WindowServer overlays.
Note that we don't actually render it as a WindowServer::Overlay, as the
window switcher uses mouse and keyboard events, and there's currently
no way for an overlay to receive events.
Most locales have a single grouping size (the number of integer digits
to be written before inserting a grouping separator). However some have
a primary and secondary size. We parse the primary size as the size used
for the least significant integer digits, and the secondary size for the
most significant.
Instead of repeating ourselves with the pattern of waiting for some
condition to be met, we can have a general method for this task,
and then we can provide the retry count, the required delay and a lambda
function for the checked condition.
When hovering an item in Terminal we now show what application will
handle it, e.g "Open app-catdog.png in ImageViewer".
If the file is its own handler, i.e an executable, it will show
"Execute myscript.sh"
In order to implement Intl.NumberFormat.prototype.formatToParts, do not
replace {currency} keys in the format pattern before ECMA-402 tells us
to. Otherwise, the array return by formatToParts will not contain the
expected currency key.
Early replacement was done to avoid resolving the currency display more
than once, as it involves a couple of round trips to search through
LibUnicode data. So this adds a non-standard method to NumberFormat to
do this resolution and cache the result.
Another side effect of this change is that LibUnicode must replace unit
format patterns of the form "{0} {1}" during code generation. These were
previously skipped during code generation because LibJS would just
replace the keys with the currency display at runtime. But now that the
currency display injection is delayed, any {0} or {1} keys in the format
pattern will cause PartitionNumberPattern to abort.
There aren't any dangling views in as of yet, but a subsequent commit
will cause the "part" variable to be a view into an internally generated
string. Therefore, after returning from PartitionNumberPattern, that
view will be pointed at freed memory.
This commit is to set the precendence of not returning a view to "part".
Previously, we were checking if the code point immediately before/after
the {currency} key was U+00A0 (non-breaking space). Instead, to handle
other spacing code points, we must check if the surrounding code point
has the separator general category.
When I originally wrote this method, I had it in LibJS, where we can't
refer to the GeneralCategory enumeration directly. This is a big TODO,
anyone outside of LibUnicode can't assume the generated enumerations
exist and must get these values by string lookup. But this function
ended up living in LibUnicode, who can reference the enumeration.
This relies on floating point division, which is not possible with
LibCrypto bigints at the moment. So, instead of completely ignoring the
remainder we now first do a bigint division, then convert the remainder
to a double, and do another native floating point division to get the
final result.
It would crash because of VERIFY(largest_unit == "nanosecond"sv) in the
final else branch when passing "week", because it's not handled in any
of the previous branches.
