Re: error with d28016d16e9a (change to jsonencode.cc)

Rik <[email protected]> Thu, 1 Oct 2020 10:41:03 -0700
Newsgroups gmane.comp.gnu.octave.maintainers
Message-ID <MTAwMDA0OS5ub21hZA.1601574069@quikprotect>

On 10/01/2020 10:24 AM, Rik wrote:
> On 10/01/2020 08:26 AM, Benjamin Abbott wrote:
>> Rik
>>
>> I’m seeing a build problem on the default branch when building on macOS (10.15.6) using Homebrew for dependencies and Apple’s clang version 12.0.0 (clang-1200.0.32.2).
>>
>> If I revert the change below, I’m able to build.
>>
>> http://hg.savannah.gnu.org/hgweb/octave/rev/d28016d16e9a
>>
>> libtool: compile:  g++ -std=gnu++11 -DHAVE_CONFIG_H -I. -Iliboctave -I./liboctave -I./liboctave/array -Iliboctave/numeric -I./liboctave/numeric -Iliboctave/operators -I./liboctave/operators -I./liboctave/system -I./liboctave/util -I./libinterp/octave-value -Ilibinterp -I./libinterp -I./libinterp/operators -Ilibinterp/parse-tree -I./libinterp/parse-tree -Ilibinterp/corefcn -I./libinterp/corefcn -I./liboctave/wrappers -I/usr/local/opt/hdf5/include -I/usr/local/Cellar/graphicsmagick/1.3.35/include/GraphicsMagick -I/usr/local/Cellar/fftw/3.3.8_2/include -I/usr/local/Cellar/fftw/3.3.8_2/include -I/usr/local/Cellar/fontconfig/2.13.1/include -I/usr/local/opt/freetype/include/freetype2 -I/usr/local/opt/freetype/include/freetype2 -I/usr/local/opt/hdf5/include -I/usr/local/opt/readline/include -I/usr/local/opt/sqlite/include -I/usr/local/opt/openssl/include -I/usr/local/opt/gettext/include -I/usr/local/opt/icu4c/include -I/usr/local/opt/qt5/include -I/usr/local/opt/sundials27/include -I/usr/local/opt/zlib/include -fPIC -D_THREAD_SAFE -pthread -Wall -W -Wshadow -Woverloaded-virtual -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -MT libinterp/corefcn/libcorefcn_la-jsonencode.lo -MD -MP -MF libinterp/corefcn/.deps/libcorefcn_la-jsonencode.Tpo -c libinterp/corefcn/jsonencode.cc  -fno-common -DPIC -o libinterp/corefcn/.libs/libcorefcn_la-jsonencode.o
>> libinterp/corefcn/jsonencode.cc:414:20: error: 'auto' not allowed in lambda parameter
>>         ([] (const auto& old_warning_state)
>>                    ^~~~
>> libinterp/corefcn/jsonencode.cc:414:26: warning: unused parameter 'old_warning_state' [-Wunused-parameter]
>>         ([] (const auto& old_warning_state)
>>                          ^
>> libinterp/corefcn/jsonencode.cc:425:20: error: 'auto' not allowed in lambda parameter
>>         ([] (const auto& old_warning_state)
>>                    ^~~~
>> libinterp/corefcn/jsonencode.cc:425:26: warning: unused parameter 'old_warning_state' [-Wunused-parameter]
>>         ([] (const auto& old_warning_state)
>>                          ^
>> In file included from libinterp/corefcn/jsonencode.cc:32:
>> In file included from libinterp/corefcn/error.h:35:
>> ./liboctave/util/unwind-prot.h:171:9: error: no matching constructor for initialization of 'std::function<void ()>'
>>       : m_fcn (std::bind (fcn, args...))
>>         ^      ~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Ben
>
> In one sense, this is easy to resolve.  Instead of using the keyword
> "auto" just specify the exact type of the underlying variable.  However,
> the compiler really should be able to handle this construct.  Could you
> try 'g++ --version'?  And is it really GNU g++ or is this a soft link to
> clang?
>

Oops, completely missed that you had already provided the version at the
top.  I happen to be using g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 where
this works correctly.  I think the issue is that 'auto' in lambdas became
acceptable only in C++14.  Could you try adding the flag '-std=gnu++14' and
see if it compiles?  If it does that will explain the difference, but we
then have a decision about how old a compiler we want to support.  2014 is
six years ago, and it will be seven years by the time the development
version of Octave becomes 7.1 so it might be acceptable to move up.

> --Rik
>