https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119215
--- Comment #18 from James K. Lowden <jklowden at gcc dot gnu.org> ---
(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.
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".
