Name namespace-scope unscoped enums#4838
Conversation
Unnamed unscoped enums at namespace scope are problematic (llvm/llvm-project#207581). Giving each such enum a name (derived from the constant it declares) is enough to avoid the issue, so do that for the header-level integral constants instead of leaving them anonymous. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
dc8beff to
649ae19
Compare
|
Update:
|
|
@vitaut please review |
|
Thanks for the PR. The linked issue says
Could you elaborate where these enumerators are re-exported? |
|
The first module to export the enum is Seastar. It doesn't name the enumerator directly. Rather it uses fmt via headers, (Seastar cannnot assume all its users consume it as a module), and some of Seastar's exported symbols depend on this enum (max_packed_args, easy to see how it would become a dependency). The second module is my fmt.cppm (I should probably switch to fmt.cc, but it isn't packaged by Fedora). Whether it is named there or not, it is referred to. When the two modules are imported by ScyllaDB, the two declarations clash. Naming those enums makes the problem go away. It was also fixed in clang, but I ask that you accept this patch as a band-aid for people who use ancient compilers like clang 22.1.8 (clang 22 isn't backporting any more, as well). gcc is also vulnerable, I'll file a bug report there too. |
|
|
But fmt's module doesn't re-export the |
|
Modules will stealthily export enough stuff to be able to build the exported inline functions. IIRC my fmt.cppm did not export max_packed_args using a using statement, and I only added it later trying to workaround the failures. I will verify and report. |
Unnamed unscoped enums at namespace scope are problematic
(llvm/llvm-project#207581). Giving each such
enum a name (derived from the constant it declares) is enough to avoid
the issue, so do that for the header-level integral constants instead of
leaving them anonymous.