From 99b96f42d6d3609d706fb38a85abee2e7127d304 Mon Sep 17 00:00:00 2001 From: David Blaikie Date: Wed, 3 Sep 2014 17:31:25 +0000 Subject: Ensure ErrorOr cannot implicitly invoke explicit ctors of the underlying type. An unpleasant surprise while migrating unique_ptrs (see changes in lib/Object): ErrorOr was implicitly convertible to ErrorOr>. Keep the explicit conversions otherwise it's a pain to convert ErrorOr to ErrorOr>. I'm not sure if there should be more SFINAE on those explicit ctors (I could check if !is_convertible && is_constructible, but since the ctor has to be called explicitly I don't think there's any need to disable them when !is_constructible - they'll just fail anyway. It's the converting ctors that can create interesting ambiguities without proper SFINAE). I had to SFINAE the explicit ones because otherwise they'd be ambiguous with the implicit ones in an explicit context, so far as I could tell. The converting assignment operators seemed unnecessary (and similarly buggy/dangerous) - just rely on the converting ctors to convert to the right type for assignment instead. llvm-svn: 217048 --- llvm/lib/Object/Binary.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'llvm/lib/Object/Binary.cpp') diff --git a/llvm/lib/Object/Binary.cpp b/llvm/lib/Object/Binary.cpp index d23ee590569..d9fef8be8e1 100644 --- a/llvm/lib/Object/Binary.cpp +++ b/llvm/lib/Object/Binary.cpp @@ -63,7 +63,8 @@ ErrorOr> object::createBinary(MemoryBufferRef Buffer, case sys::fs::file_magic::bitcode: return ObjectFile::createSymbolicFile(Buffer, Type, Context); case sys::fs::file_magic::macho_universal_binary: - return MachOUniversalBinary::create(Buffer); + return ErrorOr>( + MachOUniversalBinary::create(Buffer)); case sys::fs::file_magic::unknown: case sys::fs::file_magic::windows_resource: // Unrecognized object file format. -- cgit v1.2.3