PATCH: add a c'tor to ErrorOr that allows us to perform two user defined conversions

[Nick Lewycky via llvm-commits]

On 3 February 2016 at 21:41, David Blaikie <dblaikie at gmail.com> wrote:

> Drop the std::move (this would incorrectly move in this case, I think:
>
> std::string s;
> ErrorOr<std::string> g = s;
>
> I think?
>

I tried this case out, but it it matches "ErrorOr(T Val)" and doesn't call
my new c'tor overload at all. Do you have a similar thing for me to try?


> Perhaps you could add a test case for a case like that to ensure the move
> does not occur (you'd need a type that recorded its move operations, etc)
>

Other than that, please commit
>

I got feedback from Richard Smith off-list that I should also check for
types that convert to std::error_code. I haven't been able to get that case
to do anything wrong either.

More testcases added, but logic in ErrorOr not changed. Please review!

On Wed, Feb 3, 2016 at 6:58 PM, Nick Lewycky via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
>> The attached patch changes ErrorOr to make this code:
>>
>>   ErrorOr<string> test() { return "literal"; }
>>
>> work. Without this patch it fails because it would require two
>> user-defined conversions in a row. Please review!
>>
>> I'm not sure whether it's correct to describe this as "perfect
>> forwarding"?
>>
>> Nick
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160204/a3ea1848/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: erroror-implicitcast-2.patch
Type: text/x-patch
Size: 2711 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160204/a3ea1848/attachment.bin>