https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119215
--- Comment #17 from Harald van Dijk <harald at gigawatt dot nl> --- (In reply to James K. Lowden from comment #16) > If the report is correct IMO it would need to be reported as a Bison bug, > because the API renaming feature is supposed to allow two parsers to be used > in the same program. What am I missing? You're not missing anything, this is Bison generating code that is indeed not sufficient for the purpose of using two parsers in the same program in a standards conforming way. I do not know whether it has a proper way around it. > 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. But this is avoidable from the GCC side even if Bison does not provide a proper workaround: it is possible to just #define the name to something else, something that is unique for that translation unit.
