-
Wez Furlong authored
Summary: Running down various warning/error issues is proving to be a tiresome game of wackamole. Here's the latest issue: ``` folly/container/test/F14TestUtil.h:400:16: error: ?void* mem std::memcpy(p, &n, sizeof(std::size_t)); ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_algobase.h:64, from /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/char_traits.h:39, from /opt/rh/devtoolset-8/root/usr/include/c++/8/string:40, from /opt/rh/devtoolset-8/root/usr/include/c++/8/stdexcept:39, from /data/users/wez/scratch/dataZusersZwezZfbsource/fbcode_builder_getdeps/shipit/folly/folly/container/F14Map.h:30, from /data/users/wez/scratch/dataZusersZwezZfbsource/fbcode_builder_getdeps/shipit/folly/folly/container/test/F14MapTest.cpp:17 /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/stl_pair.h:198:12: note: ?struct std::pair<const std::basic_string<char>, int>? declared here struct pair ^~~~ ``` The targeted solution is to use `-Wno-class-memaccess` as we do with our internal builds, but that is a gcc-specific option that fails when used with the apple clang compiler. The simplest option is just to disable warning->error promotion in the cmake build, as it feels like a losing battle to keep chasing the different combinations/permutations. Reviewed By: yfeldblum Differential Revision: D14702575 fbshipit-source-id: d8daa6c9588e7c84c991a0ef86baf700bd32fe8c
78fab0fb