[CMake] Test condition failure line in ut.hpp instead of test source file

[dingari]

Expected Behavior

Output of failed test to point to the failed assert in mytest.cpp

in: /.../mytest.cpp:11 - test condition:  [(3 > 0 and 41 == 42)]

Actual Behavior

Output of failed test points to failed assert in boost/ut.hpp

in: /.../build/_deps/ut-src/include/boost/ut.hpp:2954 - test condition:  [(3 > 0 and 41 == 42)]

Steps to Reproduce the Problem

1. Download gist contents
2. Extract and cd into contents
3. run cmake -B build && cmake --build build
4. run ./build/mytest or ctest --test-dir build --output-on-failure

The output I get is

❯ ./build/mytest

Running test "sum"... FAILED
in: /.../build/_deps/ut-src/include/boost/ut.hpp:2954 - test condition:  [(3 > 0 and 41 == 42)]


===============================================================================
Suite globaltests:   1 | 1 failed
asserts: 3 | 0 passed | 1 failed

Specifications

• Version: 2.0.0
• Platform: macOS
• Subsystem:

[kris-jusiak]

Hmm, that looks like the compiler used doesn't support source_location. Can you share the compiler and version used?

The following check is being done to detect support for the source location on the library side.

#if defined(__cpp_lib_source_location)                                 
using source_location = std::source_location;                          
#else                                                                  
class source_location {                                                
 public:                                                               
  [[nodiscard]] static constexpr auto current(                         
#if (__has_builtin(__builtin_FILE) and __has_builtin(__builtin_LINE))  
      const char* file = __builtin_FILE(), int line = __builtin_LINE() 
#else                                                                  
      const char* file = "unknown", int line = {}                      
#endif                                                                 

[dingari]

Ah, I see. I think I'm using the most recent Clang version on macOS

Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: arm64-apple-darwin23.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

[kris-jusiak]

Ohh, that's bad, it seems like clang-15 introduced some bug to their builtin :/

Looking at godbolt, clang<15 works, clang-15 doens't work and clang-trunk works again. gcc seem to work just fine in all available versions.

https://godbolt.org/z/8a183GWvv

Let me dig in a bit further to see whether there is a wknd for that or the clang broke soure_lcoation builtin alltogether in 15. Note. it's also affecting not Apple clang.

[kris-jusiak]

It also seems related to clang using libstdc++ from gcc. It seems to work on clang 15 with libc++. Do you use libstdc++ by any chance?

https://godbolt.org/z/3sn1MdM53

[dingari]

Hmmm wow, this is strange!

I'm using libc++, but I guess Apple's Clang distribution is broken, at least in this version then.

[dingari]

Okay, I just tested with Clang 16 from brew and can confirm that works fine with std::source_location, so I guess Apple will just have to sort it out in their own time...

[kris-jusiak]

Thank you for checking, indeed there is something wrong with the clang-15 version :/ the builtins seem not to work and clang-15 doesn't have access to <source_location>. I'll post on the llvm project to see whether anyone can take a look, thanks again for bringing that up.