tree ee89f7653c1a6eb91ec4380bd7483cf5de67325c
parent 542f384c6652ee020977c6583fc3ed814df4fc91
author Atneya Nair <atneya@google.com> 1644621503 -0500
committer Atneya Nair <atneya@google.com> 1645817154 -0500

Disambiguate OkOrFail conversion sequences

- OkOrFail<Result<T,E>> fails to convert to the desired type
when using OR_RETURN, and the returning function expects a
Result<U, E> and E is implicitly convertible to U.
- Added test cases for various ambiguous conversion seq
- OkOrFail now only converts to the underlying code type and
Result types
- Add explicit specializations for numeric types. This is
necessary since user defined conversions can be succeeded by
numeric conversions
- Store only the error, so we can use with non-copyable types

For results where the value type is constructible via universal ref
AND this construction is valid from the underlying code type, it is not
possible to disambiguate while retaining the implicit conversion to code.
In this case, if we are compiling with cpp20 concepts, we utilize them to
solve the issue. If not, the caller will receive a compile error.

Bug: 219580167
Test: atest result_test.cpp
Test: atest libbase_result_constraint_test
Merged-In: I4bdb25fddea3093635811bf2df25cdb5b2cbe530
Change-Id: I97b4ea523f0a3c753c5d7609758e37e3dd919370