Adapt to LLVM 15 trunk libc++ dropping std::unary_/binary_function

...for C++17 and beyond with
<https://github.com/llvm/llvm-project/commit/681cde7dd8b5613dbafc9ca54e0288477f946be3>
"[libc++] Complete the implementation of N4190".  (Unless explicitly opted-in
with _LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION.  This is similar to the
MSVC standard library needing _HAS_AUTO_PTR_ETC=1 to enable those zombie
functions for quite some time now.  Only libstdc++ still supports them
unconditionally.)

Most uses of those zombie functions across LibreOffice itself and the bundled
external/* are indirectly within Boost include files.  And many (but not all) of
those Boost include files only use those zombie functions conditionally, based
on BOOST_NO_CXX98_FUNCTION_BASE.  For the (Dinkumware-derived) MSVC standard
library, workdir/UnpackedTarball/boost/boost/config/stdlib/dinkumware.hpp
already defined BOOST_NO_CXX98_FUNCTION_BASE.  So add a patch to define that
also in workdir/UnpackedTarball/boost/boost/config/stdlib/libcpp.hpp (for all of
C++11 and beyond, even if those functions were still available as deprecated in
C++11 and C++14, but which shouldn't make a difference with our C++17 baseline
anyway; only make sure that things still work if those Boost include files ever
get used by code built with gb_CXX03FLAGS).  (Patching our bundled
external/boost of course doesn't help when building with such a new libc++ and
--with-system-boost against an unpatched Boost, but lets consider that "not my
problem".  Also, one could always use a sledgehammer like passing
CPPFLAGS=-D_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION into gbuild in
such a case.)

Then there are two places that include boost/multi_array.hpp, which indirectly
includes workdir/UnpackedTarball/boost/boost/functional.hpp, which still uses
those zombie functions for non-MSVC builds (at least in the bundled
Boost 1.79.0).  Lets do a targeted
_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION in those cases.
(Alternatively, we could patch
workdir/UnpackedTarball/boost/boost/functional.hpp.  Also, I decided to make
loplugin:reservedid support the new suppression mechanism, rather than extending
its existing ignorelist even further.)

And then there is external/clucene using those zombie functions even outside of
a Boost include file, so extend the existing hack there that was already needed
for MSVC.  (And adapt the accompanying comment:  For one, we are unconditionally
"in C++17 mode" by now.  And for another, the exact places where
external/clucene uses those functions have apparently changed over time.)

Change-Id: Id0eec3bedcfddae86b16d33c02c7b5d3b3f8a16f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136579
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

1 files changed, 8 insertions, 2 deletions

diff --git a/external/clucene/Library_clucene.mk b/external/clucene/Library_clucene.mk
index c6f2895501d6..e837f9f64fb6 100644
--- a/external/clucene/Library_clucene.mk
+++ b/external/clucene/Library_clucene.mk
@@ -31,11 +31,17 @@ $(eval $(call gb_Library_add_defs,clucene,\
     -Dclucene_contribs_lib_EXPORTS \
 ))
 
-# Needed when building against MSVC in C++17 mode, as
-# workdir/UnpackedTarball/clucene/src/core/CLucene/util/Equators.h uses std::binary_function:
+# Needed when building against either libc++ or MSVC's standard library (including clang-cl builds),
+# as e.g. workdir/UnpackedTarball/clucene/src/core/CLucene/util/_Arrays.h uses std::binary_function:
+ifeq ($(HAVE_LIBCPP),TRUE)
+$(eval $(call gb_Library_add_defs,clucene, \
+    -D_LIBCPP_ENABLE_CXX17_REMOVED_UNARY_BINARY_FUNCTION \
+))
+else ifeq ($(COM),MSC)
 $(eval $(call gb_Library_add_defs,clucene, \
     -D_HAS_AUTO_PTR_ETC=1 \
 ))
+endif
 
 ifeq ($(OS),LINUX)
 $(eval $(call gb_Library_add_libs,clucene,\