Fixes:
system/core/base/include/android-base/expected.h:
186:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
195:22: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
611:13: warning: constructor accepting a forwarding reference can hide the copy and move constructors [bugprone-forwarding-reference-overload]
To quote Tom Cherry:
I'm a bit confused at what's happening there.
I think it's a bug in the linter itself.
The general solution to that problem is a heavy dose of std::enable_if<>
to hide that constructor when the 'U' parameter is the same class,
but those constructors do have the necessarily std::enable_if<> lines.
I think the problem is that the linter doesn't check that the macro
_ENABLE_IF() expands into std::enable_if<>. Let me try explicitly
putting the std::enable_if<> instead of the macro and check if it
goes away.
I expanded the macro but the linter doesn't still doesn't accept
the format of `std::enable_if_t<(condition_here)>* = nullptr`.
It does accept `typename Enable = std::enable_if_t<(condition_here), void>`,
which is the syntax used on their example here:
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-forwarding-reference-overload.html.
That latter syntax doesn't work for us.
See the Notes section on
https://en.cppreference.com/w/cpp/types/enable_if
as a reference for why what we're doing is correct.
Test: builds
Bug: 153035880
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I493ff19208cc104f5f176a36ec23fbcb914388f7
This is an alias for has_value() which is meant to be more concise, yet
more explicit than the conversions to bool.
Leave operator bool() in place for now: due to the large number of
users, removal of operator bool() needs to be broken up into incremental
stages.
Test: cd system/core && atest
Test: m
Change-Id: Ib1eb00f47d3c0f2229bb176b62687463b834f280
These operators were included because they're present in the draft
standard proposal of std::expected, but they were deemed to lead to
bugs, particularly when T is implicitly convertible to bool.
Change-Id: Ib149decf1f230198f358dc1ae0eaed71961363f6
Test: m
These move and assignment operations are conditionally noexcept, so
add that to their definitions. This is a performance issue as well as
correctness, since std containers will copy instead of move during
resize if these operations are not noexcept.
Test: build
Change-Id: I148f7eb3489e7f1dd68cc0fb0e555b56470e42da
clang-tidy flagged the anonymous namespace in the header as a warning,
but in any case, it'll be cleaner to implement this in terms of the
existing type traits.
Test: build
Change-Id: I189986d2a855c028e28dd9d62ab9da012feddc9b
Bug: 135683564
Test: Included expected.h from two different files. Builds succesfully
with the fix. Does not build without the fix.
Change-Id: If1962a3b70f7580fa652a043aaf29bf592d1926c
This is a follow-up change of 7d89fb164b.
- Some of the missing conditions for SFNAIE were added
- Fixed indentation
- The assignment operator became "= default"
Bug: 132145659
Test: libbase_test
Change-Id: Ib5232a6e5e1d3df67e185d6e8c03374105c1ce94
android::base::expected is an Android implementation of the
std::expected proposal.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0323r7.html
For usage, refer to the expected.h header file and
expected_test.cpp
Bug: 132145659
Test: libbase_test
Change-Id: I65d3a1ecf8654d9858989755dfd0065c81f7b209
