Re: Bison 3.8.2 glr2.cc portability report

[Tom Shields]

Howdy, Akim,

> On Oct 10, 2021, at 11:06 AM, Akim Demaille <akim.demaille@gmail.com> wrote:
> 
>> 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.

It isn't a problem for me if it isn’t a problem for you.  I was only running 
tests with Solaris Studio as yet another set of compilers to check portability 
of “Ox in C”, 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]
> 
> 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.
> 
> 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’t 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’t 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’ll let you 
know if shifting to separate namespaces makes any difference.

Regards,

Tom Shields