Mac M1 CMake build failure: "variable 'i' set but not used" error in third-party/flatbuffers/src/idl_gen_rust.cpp

[dbort]

When building with CMake at 77175d7 on an M1 mac

(executorch) executorch % cmake --build cmake-out -j33

...

[ 17%] Building CXX object third-party/flatbuffers/CMakeFiles/flatc.dir/grpc/src/compiler/swift_generator.cc.o
/Users/@@@@@@@/executorch/third-party/flatbuffers/src/idl_gen_rust.cpp:397:12: error: variable 'i' set but not used [-Werror,-Wunused-but-set-variable]
    size_t i = 0;
           ^
[ 17%] Linking CXX static library libgflags_nothreads.a
[ 17%] Built target gflags_nothreads_static
1 error generated.
make[2]: *** [third-party/flatbuffers/CMakeFiles/flatc.dir/src/idl_gen_rust.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [third-party/flatbuffers/CMakeFiles/flatc.dir/all] Error 2
make: *** [all] Error 2

Compiler info

% c++ --version
Apple clang version 14.0.3 (clang-1403.0.22.14.1)
Target: arm64-apple-darwin22.6.0
Thread model: posix

Reported by @mergennachin

[dbort]

It seems like we're running into a situation where -Wall meant something different back when our snapshot of flatbuffers was written, vs. now. In the past 2.5 years(!) since https://github.com/google/flatbuffers/tree/338393f854eb5ba24761a22cd9316ff5cee4eab0, it seems like the -Wunused-but-set-variable warning was added to -Wall for mac compilers. So, when the code was originally built, it was probably fine when built with -Wall -Werror. But now -Wall trips on this problem.

I dug into the flatbuffer cmake file, but couldn't find any way to override their compiler flags: everything I did in our CMakeLists.txt just added our flags to the beginning of the commandline, meaning that their flags override ours.

To unblock yourself, you can edit the offending code to remove the variable, but this is going to be a pain for people who build on mac.

Possible solutions:

• Try using a later snapshot of flatbuffers that doesn't trigger this warning. This might cause the API to change in a way that's incompatible with the Meta-internal snapshot that we use, but it would be worth finding a way to work around that in order to use the latest flatbuffer version.
• Create a fork of flatbuffers with this patch, and point to it instead.

[dbort]

Tracking internally with T160292470

[dbort]

Fixed by c351717