Re: Bison 3.8.2 glr2.cc portability report

Hi Tom,

> Le 9 oct. 2021 =C3=A0 21:31, Tom Shields =
<[email protected]> a =C3=A9crit :
>=20
> Akim,
>=20
> I thought you might be interested in the results of portability =
testing for the Ox 1.10 release (available yesterday).

Yes, I am.  Thanks a lot for this effort!


> Ox 1.10 has 6 parsers generated by bison 3.8.2, using the glr2.cc =
skeleton.
>=20
> For portability testing, I run the regression tests on each operating =
systems using each C++ compiler listed below.

This is great!

> 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.

Is this a problem?  I'd rather avoid having to work around portability =
issues of C++11 :(

I know by experience how much effort portability requires.


>  - 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]

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.

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.

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.

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.


Cheers!=