https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119215
--- Comment #22 from Harald van Dijk <harald at gigawatt dot nl> --- (In reply to James K. Lowden from comment #21) > (In reply to Harald van Dijk from comment #20) > > (In reply to James K. Lowden from comment #18) > > > A type that is not shared is not shared, and "another translation unit" > > > cannot use it, whether or not by mistake. > > The C++ standard specifies in [basic.link]p4 that named enumerations have > > linkage just like variables and functions do > > Do you refer to > > International Standard ISO/IEC 14882:2024(E) – Programming Language C++ > > ? Essentially, yes, although when we're not talking about a specific version of C++, I usually use https://eel.is/c++draft/, so in this case https://eel.is/c++draft/basic.link and https://eel.is/c++draft/basic.def.odr. > If I wrap one of the two yysymbol_kind_t in a namespace, anonymous or not, > does that solve the problem? It does. I don't know Bison well enough to know whether that is easier or more difficult as a workaround in GCC than a #define, but as a proper fix in Bison that sounds like it would be easier. > Would it be true then, that any two libraries in /usr/lib, if they are used > in the same program, must not use the same name for an enumerated type? If > so, are they relying on UB that is exposed only under LTO? For C++ static libraries, yes. Shared libraries are not covered by the standard and I am not sure whether there are relevant exceptions for that, and other languages also go by different rules; if I recall correctly, C has no similar restriction: it has no RTTI of any kind so it does not need it. > Thank you for taking the time to patiently explain the issue. I tried to be > as concrete as possible so that you could see what I'm thinking. Your > concrete example and chapter-and-verse citing are helping me understand a > feature that contradicts everything I know about C++ names. I understand > how one enum, shared between two TUs using the same header file, needs to be > consistent across the program. I don't understand how two enums used > independently and not shared, can be confused by the compiler if they're not > exposed to the linker. It's a terrible predicament, but here we are. Certainly for many of us, if we had designed C++ from scratch, the rules would be different. I'm not a fan of it either, but as you say, here we are.
