[llvm-dev] Build failures with older system libc++

Nagurne, James via llvm-dev
Thu, 15 Oct 2020 20:50:48 -0000

There exists a unit test in llvm/unittests/Support/CrashRecoveryTest.cpp that
has the following line:
EXPECT_FALSE(CRC.RunSafely(abort));

The CRC object (CrashRecoveryContext), declares RunSafely like this:
bool RunSafely(function_ref<void()> Fn);

A recent commit (b953a01b) added to the function_ref class a check in a
constructor to determine if a given Callable returns the expected type
'Ret'.
To do this, the commit utilized std::result_of_t.

+      // This is not the copy-constructor.
       std::enable_if_t<

!std::is_same<std::remove_cv_t<std::remove_reference_t<Callable>>,
-                        function_ref>::value> * = nullptr)
+                        function_ref>::value> * = nullptr,
+      // Functor must be callable and return a suitable type.
+      std::enable_if_t<std::is_void<Ret>::value ||
+                       std::is_convertible<
+                           std::result_of_t<Callable(Params...)>,
Ret>::value>
+          * = nullptr)

In libc++, std::result_of_t uses some internal checks to ensure that the type is
invokable before inferring the returned type.

In particular, prior to commit 11a18a79, these checks included a static
complete-type detection structure called '__check_complete'. The
implementation had at its core:

template <class _Tp>
struct __check_complete<_Tp>
{
    static_assert(sizeof(_Tp) > 0, "Type must be complete.");
};

Our team's downstream compiler built using a libc++ prior to 11a18a79
(particularly, __libcpp_version contains 5000) errors on the CRC.RunSafely
invocation I began with. This is because we instantiate function_ref with the
void (*)() type and attempt to call the constructor modified in commit b953a01b
using the function pointer for 'abort'. This triggers the
std::result_of_t trigger that then later involves __check_complete. When we get
to the static assert, the compiler errors: Calling sizeof on a function type is
not allowed.

Is this an instance of us needing to upgrade libc++ on the machines because our
version is not supported? We've confirmed that with the release where
__libcpp_version is 8000, the changes from 11a18a79 have been implemented and
the file compiles correctly.

JB
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201015/1fc8f51b/attachment.html>