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

[Nagurne, James via llvm-dev]

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>