[C++][Flight] test_definitions.cc failing on test-fedora-35-cpp nightly

[raulcd]

Describe the bug, including details regarding any error messages, version, and platform.

test-fedora-35-cpp is failing with the following error:

[814/1105] Building CXX object src/arrow/flight/CMakeFiles/arrow_flight_testing_objlib.dir/test_definitions.cc.o
FAILED: src/arrow/flight/CMakeFiles/arrow_flight_testing_objlib.dir/test_definitions.cc.o 
/usr/local/bin/sccache /usr/bin/g++ -DARROW_FLIGHT_EXPORTING -DARROW_HAVE_RUNTIME_AVX2 -DARROW_HAVE_RUNTIME_AVX512 -DARROW_HAVE_RUNTIME_BMI2 -DARROW_HAVE_RUNTIME_SSE4_2 -DARROW_HAVE_SSE4_2 -DARROW_HDFS -DARROW_MIMALLOC -DARROW_WITH_BROTLI -DARROW_WITH_BZ2 -DARROW_WITH_LZ4 -DARROW_WITH_RE2 -DARROW_WITH_SNAPPY -DARROW_WITH_TIMING_TESTS -DARROW_WITH_UTF8PROC -DARROW_WITH_ZLIB -DARROW_WITH_ZSTD -DBOOST_ALL_DYN_LINK -DGRPC_ENABLE_ASYNC -DGRPC_NAMESPACE_FOR_TLS_CREDENTIALS_OPTIONS=grpc::experimental -DGRPC_USE_CERTIFICATE_VERIFIER -DGRPC_USE_TLS_CHANNEL_CREDENTIALS_OPTIONS -DGTEST_LINKED_AS_SHARED_LIBRARY=1 -DJSON_DIAGNOSTICS=0 -DJSON_USE_IMPLICIT_CONVERSIONS=1 -DURI_STATIC_BUILD -I/build/cpp/src -I/arrow/cpp/src -I/arrow/cpp/src/generated -isystem /build/cpp/protobuf_ep-install/include -isystem /build/cpp/grpc_ep-install/include -isystem /build/cpp/absl_ep-install/include -isystem /arrow/cpp/thirdparty/flatbuffers/include -isystem /arrow/cpp/thirdparty/hadoop/include -isystem /build/cpp/google_cloud_cpp_ep-install/include -isystem /build/cpp/crc32c_ep-install/include -isystem /build/cpp/orc_ep-install/include -isystem /build/cpp/awssdk_ep-install/include -isystem /build/cpp/opentelemetry_ep-install/include -isystem /build/cpp/xsimd_ep/src/xsimd_ep-install/include -isystem /build/cpp/jemalloc_ep-prefix/src -isystem /build/cpp/mimalloc_ep/src/mimalloc_ep/include/mimalloc-2.0 -Wno-noexcept-type  -fdiagnostics-color=always  -Wall -Wno-conversion -Wno-sign-conversion -Wunused-result -Wdate-time -fno-semantic-interposition -msse4.2  -g -Werror -O0 -ggdb -g1 -fPIC -std=c++17 -MD -MT src/arrow/flight/CMakeFiles/arrow_flight_testing_objlib.dir/test_definitions.cc.o -MF src/arrow/flight/CMakeFiles/arrow_flight_testing_objlib.dir/test_definitions.cc.o.d -o src/arrow/flight/CMakeFiles/arrow_flight_testing_objlib.dir/test_definitions.cc.o -c /arrow/cpp/src/arrow/flight/test_definitions.cc
In file included from /usr/include/gmock/gmock-spec-builders.h:75,
                 from /usr/include/gmock/gmock-generated-function-mockers.h:47,
                 from /usr/include/gmock/gmock-function-mocker.h:39,
                 from /usr/include/gmock/gmock.h:61,
                 from /arrow/cpp/src/arrow/flight/test_util.h:20,
                 from /arrow/cpp/src/arrow/flight/test_definitions.cc:30:
/usr/include/gmock/gmock-matchers.h: In instantiation of 'bool testing::internal::HasSubstrMatcher<StringType>::MatchAndExplain(const MatcheeStringType&, testing::MatchResultListener*) const [with MatcheeStringType = std::basic_string_view<char>; StringType = std::__cxx11::basic_string<char>]':
/usr/include/gtest/gtest-matchers.h:484:35:   required from 'bool testing::PolymorphicMatcher<Impl>::MonomorphicImpl<T>::MatchAndExplain(T, testing::MatchResultListener*) const [with T = const std::basic_string_view<char>&; Impl = testing::internal::HasSubstrMatcher<std::__cxx11::basic_string<char> >]'
/usr/include/gtest/gtest-matchers.h:483:18:   required from here
/usr/include/gmock/gmock-matchers.h:760:23: error: invalid initialization of reference of type 'const std::__cxx11::basic_string<char>&' from expression of type 'const std::basic_string_view<char>'
  760 |     const StringType& s2(s);
      |                       ^~
[815/1105] Linking CXX shared library debug/libarrow_flight.so.1300.0.0

Based on the crossbow report these are the commits that were added on the first failure some days ago:
77d87a9...f93929f
It does seem related to: 9f183fc

Component(s)

C++, FlightRPC

[pitrou]

@lidavidm

[pitrou]

It might also be related to #36379.

[lidavidm]

I guess we can't use matchers, hmm.

[pitrou]

Well, we use them in many places already, don't we? This seems more of an issue of not supporting C++17 stdlib classes in matchers.