Commit Graph

10 Commits

Author SHA1 Message Date
Timothy Flynn
604d5f5bca AK+Everywhere: Do not implicitly copy variables in TRY macros
For example, consider cases where we want to propagate errors only in
specific instances:

    auto result = read_data(); // something like ErrorOr<ByteBuffer>
    if (result.is_error() && result.error().code() != EINTR)
        continue;
    auto bytes = TRY(result);

The TRY invocation will currently copy the byte buffer when the
expression (in this case, just a local variable) is stored into
_temporary_result.

This patch binds the expression to a reference to prevent such copies.
In less trival invocations (such as TRY(some_function()), this will
incur only temporary lifetime extensions, i.e. no functional change.
2023-02-10 09:08:52 +00:00
Andrew Kaster
f5d253dcfa Everywhere: Fully qualify IsLvalueReference in TRY() macros
If USING_AK_GLOBALLY is not defined, the name IsLvalueReference might
not be available in the global namespace. Follow the pattern established
in LibTest to fully qualify AK types in macros to avoid this problem.
2023-01-15 00:56:31 +00:00
Timothy Flynn
afc0e461e1 AK+Everywhere: Disallow returning a reference from a fallible expression
This will silently make a copy. Rather than masking this behavior, let's
explicitly disallow it.
2023-01-13 18:50:47 -05:00
Linus Groh
5103e08b77 AK: Ignore -Wshadow in TRY() and MUST()
This makes the warning in CLion disappear when nesting them.
2022-12-06 21:31:00 +00:00
Paul Herman
d989c50c90 AK: Document the non-standard extensions in TRY
I'm not sure there's a material improvement from this patch. However,
I've been reading the error handling code from multiple projects and
was excited to see Serenity being able to handle assignment
(`auto x = TRY(make_x())`) the same way as actions (`TRY(do_x())`).
I think it's worth documenting that this is only possible due to
non-standard extensions.
2022-10-16 22:05:42 +02:00
Idan Horowitz
8a879e205b AK: Mark the error branch of the TRY() macro as unlikely
This results in a measurable (and free!) 2% improvement in test-js
run time.
2022-01-16 02:01:23 +02:00
Andreas Kling
cd49f30bea AK+LibJS: Simplify MUST() and move it from LibJS to AK/Try.h
This is generally useful so let's move it to AK. Also it seems that we
don't need the temporary variable hack anymore, so let's lose that.
2021-11-10 21:58:58 +01:00
Andreas Kling
79fa9765ca Kernel: Replace KResult and KResultOr<T> with Error and ErrorOr<T>
We now use AK::Error and AK::ErrorOr<T> in both kernel and userspace!
This was a slightly tedious refactoring that took a long time, so it's
not unlikely that some bugs crept in.

Nevertheless, it does pass basic functionality testing, and it's just
real nice to finally see the same pattern in all contexts. :^)
2021-11-08 01:10:53 +01:00
Linus Groh
cbdd069279 AK: Rename the local variable in the TRY() macro to avoid name clashes
"result" is a tad bit too generic to provide a clash-free experience -
we found instances in LibJS where this breaks already. Essentially this
doesn't work:

    auto foo = TRY(bar(result));

Because it expands to the following within the TRY() scope:

    {
        auto result = bar(result);
        ...
    }

And that of course fails:

    error: use of ‘result’ before deduction of ‘auto’

The simple solution here is to use a name that is much less likely to
clash with anything used in the expression ("_temporary_result"). :^)
2021-09-15 23:46:53 +01:00
Andreas Kling
b4d8e166d8 AK: Add a TRY(expression) macro to simplify the unwrap-or-return pattern
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>
2021-09-05 14:08:12 +02:00