Re: Bison 3.8.2 glr2.cc portability report

Howdy, Akim,

> On Oct 10, 2021, at 11:06 AM, Akim Demaille <[email protected]> =
wrote:
>=20
>> The Solaris Studio errors noted below are due to a defect in support =
for the C++ 2011: a noexcept operator within a noexcept specifier for an =
overloaded version of std::swap in several header files is the source of =
the error messages above.  The exact same signature is found in the =
equivalent GNU & LLVM header files.  As an experiment (on Solaris 11.4), =
I edited the offending signature in the header files to bypass the =
problem, which allowed Ox to compile.  Ox then failed to link due to =
several versions of the C++ std::ostream '<<' operator missing from the =
C++ library.
>=20
> Is this a problem?  I'd rather avoid having to work around portability =
issues of C++11 :(
>=20
> I know by experience how much effort portability requires.

It isn't a problem for me if it isn=E2=80=99t a problem for you.  I was =
only running tests with Solaris Studio as yet another set of compilers =
to check portability of =E2=80=9COx in C=E2=80=9D, but I have no special =
investment in Solaris, which Oracle has clearly killed off.

>> - Homebrew GNU C++ 11.2: compile warnings for each parser:
>>     agc-Lfile.cc:2711:16: warning: 'AGC::lexer::glr_stack' has a =
field 'AGC::lexer::glr_stack::yyerror_range' whose type uses the =
anonymous namespace [-Wsubobject-linkage]
>>     agc-Lfile.cc:2711:16: warning: 'AGC::lexer::glr_stack' has a =
field 'AGC::lexer::glr_stack::yystateStack' whose type uses the =
anonymous namespace [-Wsubobject-linkage]
>=20
> I am unable to reproduce it on the "Several parsers" test in the test =
suite (after having added -Wsubobject-linkage to the list of warning =
flags to use).  I used g++-mp-11 (MacPorts gcc11 11.2.0_1) 11.2.0.

Curious, as I got this error from every GNU C++ release I tried across =
macOS, Linux, and Windows, save ONLY for GNU C++ 7.3 on Solaris 11.4, =
which I admit left me wondering just a bit.  There must be something =
about the Ox source that triggers this.

> But I can see the configuration.  Indeed we define the glr_stack class =
in a named namespace, but in the *.cc file only, and glr_stack uses =
glr_stack_item, which is defined in the same *.cc, but within an unnamed =
namespace.
>=20
> I can see why in general this is dangerous, but in the present case, I =
don't see how it could go wrong: every bit is in the same *.cc file.

I agree that this doesn=E2=80=99t appear to be an actual issue, at least =
in the Ox-specific case.

> We could define glr_stack_item in a named namespace (since it is my =
understanding Tom that you no longer try to have several parsers in the =
same namespace), but it still annoys me because I was happy to limit the =
number of visible symbols exposed by the compilation unit.  In order to =
help speeding up linking.

I actually haven=E2=80=99t changed the Ox parser specs to use separate =
namespaces for each parser yet, although that is on my list of things to =
do for Ox 1.10.1.  It may be that the warnings will vanish when I make =
this change.  I=E2=80=99ll let you know if shifting to separate =
namespaces makes any difference.

Regards,

Tom Shields=