The way we use classes like Kernel::KResultOr<T> and AK::Result<T, E>
makes checking for errors (and short-circuiting returns) quite verbose.
This patch adds a new TRY(expression) macro that either evaluates to
the released result of the expression if successful, or returns the
error if not.
Before:
auto foo_or_error = get_foo();
if (foo_or_error.is_error())
return foo_or_error.release_error();
auto foo = foo_or_error.release_value();
After:
auto foo = TRY(get_foo());
The macro uses a GNU C++ extension which is supported by GCC, Clang,
Intel C++, and possibly others. It's not *ideal*, but since it makes our
codebase considerably nicer, let's try(!) it out. :^)
Co-authored-by: Ali Mohammad Pur <mpfard@serenityos.org>
This commit moves the KResult and KResultOr objects to Kernel/API to
signify that they may now be freely used by userspace code at points
where a syscall-related error result is to be expected. It also exposes
KResult and KResultOr to the global namespace to make it nicer to use
for userspace code.
This is the idiomatic way to declare type aliases in modern C++.
Flagged by Sonar Cloud as a "Code Smell", but I happen to agree
with this particular one. :^)
This function is currently only ever used to create the init process
(SystemServer). It had a few idiosyncratic things about it that this
patch cleans up:
- Errors were returned in an int& out-param.
- It had a path for non-0 process PIDs which was never taken.
REQUIRE_PROMISE and REQUIRE_NO_PROMISES were macros for some reason,
and used all over the place.
This patch adds require_promise(Pledge) and require_no_promises()
to Process and makes the macros call these on the current process
instead of inlining code everywhere.
freq_bin was converted to double after it was calculated, so there was
a much higher probability it could be 0 instead of some comma number,
which meant that the bars always stayed on top.
The freq_bin in bins_per_group was multiplied only to be divided later,
which could even result in a crash if you set higher buffer size
(like 1000ms) in PlaybackManager, due to rounding errors I presume.
Casting u64 to float is probably not a safe thing to do. Also, keep
time deltas in u64 values as they can easily wrap between calculations.
This fixes CPU usage calculation when a process is spinning in a loop.