RTTI dependency added by std::any
Description
When compiling with -fno-rtti using clang, ninja on VS 2022 17.4.3 the build will fail.
This line seems to be causing the issue:
#if defined(JSON_HAS_CPP_17)
#include <any>
#include <string_view>
#endif
Including any requires rtti to be on.
This error was produced using ninja and the VS 2022 17.4.3 clang compiler.
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.34.31933\include\any(22,2): error GDF32A4F7: class any requires static RTTI.
#error class any requires static RTTI.
^
Reproduction steps
Build using ninja and -fno-rtti and the VS 2022 17.4.3 clang compiler.
Expected vs. actual results
Expect: compilation successful Actual: #error class any requires static RTTI.
Minimal code example
No response
Error messages
No response
Compiler and operating system
MSVC 17.4.3
Library version
3.11.2
Validation
- [ ] The bug also occurs if the latest version from the
developbranch is used. - [ ] I can successfully compile and run the unit tests.
This is odd. Does the standard require std::any to only work with RTTI?
It should not. See SO, example using gcc 8.1, example using clang 8,
This might be an issue with the MSVC STL.
Thanks - maybe you can open an issue at https://github.com/microsoft/STL/issues ?
Well i did some more testing and am not so sure this is the issue...
It seems msvc 19.14 is fine with std::any and disabled RTTI.
@barcode Were you using the clang-cl compiler builtin with VS ?
@vongkitt No, I don't have windows and hence i am using godbolt.org for my tests and this way i can share them here. I don't think godbolt has any msvc-clang option.
The strange thing about all of this: The Linux version clang is fine with using std::any when deactivating rtti while the msvc-clang is not.
Looking at the path in your error message
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.34.31933\include\any
This looks like the msvc stl.
If you open the <any> file, you probably can see the Microsoft Copyright. This would confirm my hunch.
Also there is a similar issue with any and static rtti: https://github.com/microsoft/STL/issues/3114
@barcode Yes MS built-in clang version is using the MS STL by default so your hunch is correct
Is this related to #4046?
Is this related to #4046?
Yes. #4096 fixes compiling with Clang-cl & -fno-rtti in combination with Microsoft STL.