For compatibility reasons, the Windows version of Clang defines _MSC_VER, meaning libassert detects the compiler as MSVC
|
#ifdef _MSC_VER |
|
#define LIBASSERT_IS_MSVC 1 |
|
#define LIBASSERT_MSVC_VERSION _MSC_VER |
|
#else |
|
#define LIBASSERT_IS_MSVC 0 |
|
#define LIBASSERT_MSVC_VERSION 0 |
|
#endif |
This causes some issues. For example, ASSERT_VAL eventually calls the LIBASSERT_INVOKE_VAL_PRETTY_FUNCTION_ARG macro which in this scenario relies on a built-in that Clang doesn't support:
|
#if LIBASSERT_IS_MSVC |
|
#define LIBASSERT_INVOKE_VAL_PRETTY_FUNCTION_ARG ,libassert::detail::pretty_function_name_wrapper{libassert_msvc_pfunc} |
|
#else |
I think this can be fixed by just replacing the #ifdef _MSC_VER with #if defined(_MSC_VER) && !defined(__clang__). It fixes the ASSERT_VAL issue, but I'm not sure what else might change (though it should be fine since presumably it'll just switch to the clang version of libassert everywhere else as well).
For compatibility reasons, the Windows version of Clang defines
_MSC_VER, meaning libassert detects the compiler as MSVClibassert/include/libassert/platform.hpp
Lines 52 to 58 in b90077a
This causes some issues. For example,
ASSERT_VALeventually calls theLIBASSERT_INVOKE_VAL_PRETTY_FUNCTION_ARGmacro which in this scenario relies on a built-in that Clang doesn't support:libassert/include/libassert/assert.hpp
Lines 687 to 689 in b90077a
I think this can be fixed by just replacing the
#ifdef _MSC_VERwith#if defined(_MSC_VER) && !defined(__clang__). It fixes theASSERT_VALissue, but I'm not sure what else might change (though it should be fine since presumably it'll just switch to the clang version of libassert everywhere else as well).