[tinadu1018]

Summary

Make the -fcoroutines usage requirement depend on the consuming C++ compiler, rather than the compiler that configured FBThrift.

thrift_configure_target currently checks CMAKE_CXX_COMPILER_ID at configure time, then exports a language-only expression:

$<$<COMPILE_LANGUAGE:CXX>:-fcoroutines>

When FBThrift is built with GCC and its installed targets are consumed by Clang, this passes the GCC-specific flag to Clang. A downstream -Werror build then fails:

clang++: error: argument unused during compilation: '-fcoroutines'
[-Werror,-Wunused-command-line-argument]

Observed in Velox's Linux ASAN/UBSAN CI.

Regression history

The flag itself is not new; exporting it to downstream consumers is what changed.

• v2026.09.07.00 already used -fcoroutines, but through directory-level add_compile_options(). It affected FBThrift's own compilation and was not exported as a requirement for consumers of the installed targets.
• On September 10, 2026, commit 734f1641, "Express the C++ standard as a target usage requirement," moved these settings into thrift_configure_target. Its PUBLIC call sites also exported the language-only -fcoroutines option.
• Velox's upgrade to v2026.10.26.00 picked up that change. A GCC-built FBThrift package now passes the flag to Velox's Clang sanitizer build, where -Werror makes it fatal. The configure-time GNU check describes the producer, while the exported expression checks only whether the consumer is compiling C++.

This is a change in the exported build requirements, not a new Velox requirement. The public C++20 requirement is intentional; this PR preserves it while selecting -fcoroutines according to the consuming compiler.

Fix

Replace the configure-time condition with:

$<$<COMPILE_LANG_AND_ID:CXX,GNU>:-fcoroutines>

This evaluates the compiler for each consuming target. GNU C++ compilation retains the option, including when consuming a Clang-built package; Clang and other compilers do not receive it. No compiler warnings are suppressed, and no dependency versions, workflows, runtime code, or xxhash discovery are changed.

A same-compiler build does not expose this boundary: GCC accepts the original flag, while a Clang-configured FBThrift omits it entirely. The existing public Linux workflow configures, builds, and tests one tree rather than installing with GCC and compiling a downstream consumer with Clang.

Validation

Focused Ubuntu Linux (WSL) regression using GCC 13.3 and Clang 18.1.3. Built and installed real thrift_common using the production configuration/export functions, then compiled and ran a C++20 coroutine consumer that calls the installed library, with -Wall -Wextra -Werror and ASAN/UBSAN enabled.

Producer	Consumer	Before	After
GCC	GCC	Pass	Pass
GCC	Clang	Fails with the error above	Pass
Clang	GCC	Pass	Pass
Clang	Clang	Pass	Pass

Also checked the generated compile commands: after the fix, only GNU consumers receive -fcoroutines. This was a focused export regression, not a local run of the full FBThrift test suite.

[meta-codesync]

@vitaut has imported this pull request. If you are a Meta employee, you can view this in D129638627.

[meta-codesync]

@vitaut merged this pull request in 2e6cd77.

[vitaut]

Thank you!