https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119215
--- Comment #19 from Sam James <sjames at gcc dot gnu.org> --- (In reply to James K. Lowden from comment #18) > (In reply to Harald van Dijk from comment #17) > > (In reply to James K. Lowden from comment #16) > > > No uses of that symbol have external linkage. > > > > But the rules are for the type itself, and it matters even with GCC: > > compiling that translation unit causes the typeinfo for the enum to be > > emitted, which could break if another translation unit defines a type with > > the same name, needs the typeinfo for its own type, and ends up getting the > > typeinfo for the enum instead. > > A type that is not shared is not shared, and "another translation unit" > cannot use it, whether or not by mistake. > > In the case of yysymbol_kind_t, we have 4 functions in each of two files > that use the same name to refer to *different* enumerations. Those enums > have no linkage, external or internal. None of those functions have > external linkage either. The only yysymbol_kind_t they can refer to is the > one defined in the same TU as the function. No, that's not the rule. See https://stackoverflow.com/questions/1358400/what-is-external-linkage-and-internal-linkage. It has external linkage even without 'extern'. > > I have spent the day reviewing ODR and odr-used, and ISTM there is ample > confusion abroad. Even this in cppreference.com: > > > if one .cpp file defines struct S { int x; }; and the other .cpp file > > defines struct S { int y; };, the behavior of the program that links > > them together is undefined. > > Not true. The linker does not link types. It links values: data and > functions. The "program that links them together" would link a variable > defined on S. If there is such a variable, and it is referenced with > extern, *then* there's an ODR violation: two definitions for the same > *value*, of which the linker can choose only one. Absent a shared value, > though, they're just two definitions that both happen to be called "S". With LTO, functions may be inlined into objects from another TU and then the type has to be disambiguated.
