Re: [lmi] New CI breakage due to gcc 12 updates

[Greg Chicares]

On 7/23/22 23:28, Vadim Zeitlin wrote:
[...]
> /opt/lmi/third_party/src/cgicc/Cgicc.cpp:45:37: error: 'template<class _Arg, 
> class _Result> struct std::unary_function' is deprecated 
> [-Werror=deprecated-declarations]
>    45 | class FE_nameCompare : public STDNS unary_function<FormEntry, bool>
>       |                                     ^~~~~~~~~~~~~~
> 
> To fix this normally I would just stop inheriting from unary_function<>,
> but this involves modifying third party code, so perhaps you'd prefer to
> suppress the deprecation warning for it?

Yes. If we want to modify it, then we must either
 - add a new patch, to be applied after 'cgicc-3.1.4.patch'; or
 - alter the existing patch;
and both those ideas sound like too much work for too little gain.

In 'compiler_*_warnings.make' we already have a list of
inhibited warnings; shouldn't we just add this:

  $(cgicc_objects): clang_common_extra_warnings += \
+   -Wno-deprecated-declarations \
    -Wno-shorten-64-to-32 \
    -Wno-unknown-pragmas \
    -Wno-zero-as-null-pointer-constant \

 $(cgicc_objects): gcc_common_extra_warnings += \
   -Wno-conversion \
+  -Wno-deprecated-declarations \
   -Wno-zero-as-null-pointer-constant \

for clang and gcc, respectively?

I imagine std::unary_function will be provided forever, even
though deprecated, because it helps in cases like this and can
do no harm, and C++20 [zombie.names] says no one else can
define it with a different meaning.

> In fact, I've never really
> understood if CGI-related code was still used or not (and by "still" I mean
> as far back as in 2005 when I first looked at it), so perhaps the time has
> come to just drop it?

Perhaps. But I won't rush a decision like that. It's validated code
that continues to pass its regression tests. We might just as well
say that the CLI builds are "unused".

> /__w/lmi/lmi/md5sum.cpp:100:32:   required from here
> /usr/include/c++/12/bits/stl_construct.h:95:14: error: noexcept-expression 
> evaluates to 'false' because of a call to 
> 'md5sum_for_file::md5sum_for_file(fs::path&&, std::string&&, md5_file_mode)' 
> [-Werror=noexcept]
>    95 |     noexcept(noexcept(::new((void*)0) _Tp(std::declval<_Args>()...)))
>       |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In file included from /__w/lmi/lmi/md5sum.cpp:26:
> /__w/lmi/lmi/md5sum.hpp:50:5: note: but 
> 'md5sum_for_file::md5sum_for_file(fs::path&&, std::string&&, md5_file_mode)' 
> does not throw; perhaps it should be declared 'noexcept'
>    50 |     md5sum_for_file(fs::path&& path, std::string&& sum, md5_file_mode 
> mode)
>       |     ^~~~~~~~~~~~~~~
> ---------------------------------- >8 --------------------------------------
> 
> It appears that using emplace_back() requires the corresponding ctor to not
> throw in C++20, which is news to me, to be honest, but we should make the
> ctor noexcept anyhow, of course.

Agreed. The <type_traits> library already distinguishes
  is_move_constructible
  is_nothrow_move_constructible
and the "Cpp17MoveInsertable" requirement in the C++20 standard
should perhaps be augmented by a new "CppXXNoThrowMoveInsertable"
name to describe this requirement accurately.

>  The third problem is the most mysterious one.
Solved elsewhere in this thread.