Re: Bison 3.8.2 glr2.cc portability report

[Akim Demaille]

Hi Tom,

> Le 9 oct. 2021 à 21:31, Tom Shields <thomas.evans.shields@icloud.com> a écrit 
> :
> 
> Akim,
> 
> 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.
> 
> 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!