Clang 17 breaks Status adapters on macos

[NeejWeej]

Describe the bug
On clang 17, creating status adapters fail, specifically, on this line: https://github.com/Point72/csp/blob/main/cpp/csp/engine/StatusAdapter.h#L47
On clang 17, a dynamic_cast to StringStructField fails, but a dynamic_cast to NonNativeStructField works.
On clang 16, the StringStructField cast succeeds

To Reproduce
This PR with clang 16 pinned, passes:
#397

This PR with clang unpinned (pulls in 17) fails on creating status adapters:
#399

Expected behavior
PR #397 shows the expected behavior

Error Message
TypeError: Struct.h:getMetaField:680:TypeError: Status - provided struct type Status expected type � for field msg but got type STRING for Status
[bt]: (0) 0 _csptypesimpl.so 0x000000010f65bc48 _ZN3csp9Exception5setbtEv + 48
[bt]: (1) 1 _cspimpl.so 0x000000010f1afe8c _ZN3csp9ExceptionC2EPKcRKNSt3__112basic_stringIcNS3_11char_traitsIcEENS3_9allocatorIcEEEES2_S2_i + 476
[bt]: (2) 2 _cspimpl.so 0x000000010f3190cc ZN3csp10StructMeta12getMetaFieldINSt3__112basic_stringIcNS2_11char_traitsIcEENS2_9allocatorIcEEEEEENS2_10shared_ptrINS_11StructField6upcastIT_E4typeEEEPKcSH + 1200
[bt]: (3) 3 _cspimpl.so 0x000000010f318440 _ZN3csp13StatusAdapterC2EPNS_6EngineERNSt3__110shared_ptrIKNS_7CspTypeEEENS_4EnumINS_14PushModeTraitsEEEPNS_9PushGroupE + 516
[bt]: (4) 4 _cspimpl.so 0x000000010f317ddc _ZN3csp14AdapterManager19createStatusAdapterERNSt3__110shared_ptrIKNS_7CspTypeEEENS_4EnumINS_14PushModeTraitsEEE + 116
[bt]: (5) 5 _cspimpl.so 0x000000010f1eb5ec ZN3csp6pythonL21create_status_adapterEPNS_14AdapterManagerEPNS0_8PyEngineEP7_objectNS_4EnumINS_14PushModeTraitsEEES6 + 84
[bt]: (6) 6 _cspimpl.so 0x000000010f1eb6bc ZNSt3__110__function6__funcIPFPN3csp13StatusAdapterEPNS2_14AdapterManagerEPNS2_6python8PyEngineEP7_objectNS2_4EnumINS2_14PushModeTraitsEEESB_ENS_9allocatorISG_EEFPNS2_12InputAdapterES6_S9_SB_SE_SB_EEclEOS6_OS9_OSB_OSE_SP + 64
[bt]: (7) 7 _cspimpl.so 0x000000010f23499c ZN3csp6python21PyInputAdapterWrapper13createAdapterENSt3__18functionIFPNS_12InputAdapterEPNS_14AdapterManagerEPNS0_8PyEngineEP7_objectNS_4EnumINS_14PushModeTraitsEEESB_EEESB + 284
[bt]: (8) 8 _cspimpl.so 0x000000010f1e8100 ZN3csp6pythonL22create__status_adapterEP7_objectS2 + 72
[bt]: (9) 9 python3.12 0x0000000102e82688 cfunction_call + 308
[bt]: (10) 10 python3.12 0x0000000102e266d8 _PyObject_MakeTpCall + 316
[bt]: (11) 11 python3.12 0x0000000102f557c0 _PyEval_EvalFrameDefault + 57428
[bt]: (12) 12 python3.12 0x0000000102e2a848 method_vectorcall + 188
[bt]: (13) 13 python3.12 0x0000000102e27094 _PyVectorcall_Call + 132
[bt]: (14) 14 python3.12 0x0000000102f5748c _PyEval_EvalFrameDefault + 64800
[bt]: (15) 15 python3.12 0x0000000102e26ab8 _PyObject_FastCallDictTstate + 156
[bt]: (16) 16 python3.12 0x0000000102ea7d08 slot_tp_call + 332
[bt]: (17) 17 python3.12 0x0000000102e266d8 _PyObject_MakeTpCall + 316
[bt]: (18) 18 python3.12 0x0000000102f557c0 _PyEval_EvalFrameDefault + 57428
[bt]: (19) 19 python3.12 0x0000000102e26ab8 _PyObject_FastCallDictTstate + 156
[bt]: (20) 20 python3.12 0x0000000102ea7d08 slot_tp_call + 332
[bt]: (21) 21 python3.12 0x0000000102e274ac _PyObject_Call + 184
[bt]: (22) 22 python3.12 0x0000000102f5748c _PyEval_EvalFrameDefault + 64800
[bt]: (23) 23 python3.12 0x0000000102e26ab8 _PyObject_FastCallDictTstate + 156
[bt]: (24) 24 python3.12 0x0000000102ea7d08 slot_tp_call + 332
[bt]: (25) 25 python3.12 0x0000000102e266d8 _PyObject_MakeTpCall + 316
[bt]: (26) 26 python3.12 0x0000000102f557c0 _PyEval_EvalFrameDefault + 57428
[bt]: (27) 27 python3.12 0x0000000102e26ab8 _PyObject_FastCallDictTstate + 156
[bt]: (28) 28 python3.12 0x0000000102ea7d08 slot_tp_call + 332
[bt]: (29) 29 python3.12 0x0000000102e266d8 _PyObject_MakeTpCall + 316
[bt]: (30) 30 python3.12 0x0000000102f557c0 _PyEval_EvalFrameDefault + 57428
[bt]: (31) 31 python3.12 0x0000000102e26ab8 _PyObject_FastCallDictTstate + 156
[bt]: (32) 32 python3.12 0x0000000102ea7d08 slot_tp_call + 332
[bt]: (33) 33 python3.12 0x0000000102e266d8 _PyObject_MakeTpCall + 316
[bt]: (34) 34 python3.12 0x0000000102f557c0 _PyEval_EvalFrameDefault + 57428
[bt]: (35) 35 python3.12 0x0000000102f4683c PyEval_EvalCode + 300
[bt]: (36) 36 python3.12 0x0000000102f43444 builtin_exec + 1412
[bt]: (37) 37 python3.12 0x0000000102e832a0 cfunction_vectorcall_FASTCALL_KEYWORDS + 144
[bt]: (38) 38 python3.12 0x0000000102e2723c PyObject_Vectorcall + 88
[bt]: (39) 39 python3.12 0x0000000102f557c0 _PyEval_EvalFrameDefault + 57428
[bt]: (40) 40 python3.12 0x0000000102fec0ec pymain_run_module + 292
[bt]: (41) 41 python3.12 0x0000000102febb04 Py_RunMain + 2612
[bt]: (42) 42 python3.12 0x0000000102fec984 pymain_main + 628
[bt]: (43) 43 python3.12 0x0000000102dbf7c0 main + 56
[bt]: (44) 44 dyld 0x000000019761b154 start + 2476

[NeejWeej]

From here: https://releases.llvm.org/17.0.1/tools/clang/docs/ReleaseNotes.html

Improved code generation for dynamic_cast to a final type. Instead of dispatching to the runtime library to compare the RTTI data, Clang now generates a direct comparison of the vtable pointer in cases where the ABI requires the vtable for a class to be unique. This optimization can be disabled with -fno-assume-unique-vtables. This optimization is not yet implemented for the MS C++ ABI.

This seems like the culprit

[robambalu]

Have you tried compiling with that flag set for MacOS builds?
Also I noticed the failed test was websocket, if other tests ran before websocket successfully its possible the issue is with websocket code specifically

[NeejWeej]

Have you tried compiling with that flag set for MacOS builds?

Yes, adding that flag fixes the issue (but its only available in clang 17), here is how I added the fix: https://github.com/Point72/csp/pull/378/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR207

Also I noticed the failed test was websocket, if other tests ran before websocket successfully its possible the issue is with websocket code specifically

None of the tests we actually run in github CICD tested the status adapter, the websockets one was the first one. I can replicate it with the parquetAdapter tests by adding a dummy ".status()" call to the ParquetReader and calling csp.print on it to make sure its not pruned (using clang 17, with clang 16 everything works fine). I get the exact same error with:

TypeError: Struct.h:getMetaField:680:TypeError: Status - provided struct type Status expected type for field msg but got type STRING for Status