...and change the parameter types from i64 to double, as predicted by
a FIXME. The issue here is that integer division with a negative
dividend doesn't yield the same result as floating point division
wrapped in floor().
Additionally, the `days` variable needs to be signed.
Two instances of comparing a bool with == true or == false, and one
instance where we can just return an expression instead of checking it
to return true on succeess and false on failure.
... In files included from Kernel/Thread.cpp or Kernel/Process.cpp
Some places the warning is suppressed, because we do not want a const
object do have non-const access to the returned sub-object.
In AK::Function::CallableWrapper::init_and_swap(), clang-tidy wants us
to mark the destination argument as pointer to const, which doesn't work
because we use placement new to construct a move'd *this into.
cert-dcl50-cpp: No variadic functions, suppressed in RefCounted and
ThreadSafeRefCounted for implementing the magic one_ref_left and
will_be_destroyed functions.
cert-dcl58-cpp: No opening ::std, suppressed in the places we put names
in ::std to aid tools (move, forward, nullptr_t, align_val_t, etc).
Either not returning *this, or in the case of Variant, not checking for
self assignment. In AK::Atomic, we can't return *this due to the wrapper
semantics Atomic implements.
Using `l` for long double causes a clang-tidy warning, so use all caps
suffixes for all of the AK::abs() overloads for consistency. Also, avoid
leaking the internal __DEFINE_GENERIC_ABS macro.
The definition of VERIFY_NOT_REACHED() as `assert(false)` causes the
tool to suggest converting it to a static_assert. Which doesn't make
any sense in context for what the macro is trying to do: crash the
program at runtime.
If we want to use clang-tidy on the codebase, we'll need to build
clang-tidy from an LLVM that has been patched and built with Serenity
cross-compilation support.
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.
