Tests fail to build on current Debian sid

[wRAR]

Hello!
I'm investigating the build failure of the range-v3 package in Debian. I tried to build the current git HEAD and it also fails, with the same error:

[  1%] Building CXX object test/CMakeFiles/range.v3.config.dir/config.cpp.o
cd /range-v3/build/test && /usr/lib/ccache/c++  -I/range-v3/include -O3 -DNDEBUG -std=c++14 -Wall -Wextra -Werror -fdiagnostics-show-template-tree -ftemplate-backtrace-limit=0 -fomit-frame-pointer -Ofast -fstrict-aliasing -ffast-math -fsized-deallocation -march=native -mtune=native -DRANGES_CXX_ALIGNED_NEW=0 -fconcepts -pedantic -pedantic-errors -Wno-padded -Wno-old-style-cast -Wno-noexcept-type -MD -MT test/CMakeFiles/range.v3.config.dir/config.cpp.o -MF CMakeFiles/range.v3.config.dir/config.cpp.o.d -o CMakeFiles/range.v3.config.dir/config.cpp.o -c /range-v3/test/config.cpp
In file included from /range-v3/include/range/v3/detail/config.hpp:67,
                 from /range-v3/test/config.cpp:12:
/range-v3/include/meta/meta_fwd.hpp:351:40: error: expected type-name before ‘invocable’
  351 |         template <META_TYPE_CONSTRAINT(invocable) F, typename L>
      |                                        ^~~~~~~~~
/range-v3/include/meta/meta_fwd.hpp:155:35: note: in definition of macro ‘META_TYPE_CONSTRAINT’
  155 | #define META_TYPE_CONSTRAINT(...) __VA_ARGS__
      |                                   ^~~~~~~~~~~
/range-v3/include/meta/meta_fwd.hpp:351:40: error: ISO C++ forbids declaration of ‘invocable’ with no type [-fpermissive]
  351 |         template <META_TYPE_CONSTRAINT(invocable) F, typename L>
      |                                        ^~~~~~~~~
/range-v3/include/meta/meta_fwd.hpp:155:35: note: in definition of macro ‘META_TYPE_CONSTRAINT’
  155 | #define META_TYPE_CONSTRAINT(...) __VA_ARGS__
      |                                   ^~~~~~~~~~~
/range-v3/include/meta/meta_fwd.hpp:351:51: error: expected ‘>’ before ‘F’
  351 |         template <META_TYPE_CONSTRAINT(invocable) F, typename L>
      | 

(there are more errors if compiling with parallel jobs, this is just the first one with -j1)

Not sure wat env details are important, this is current Debian sid with gcc 14.2.0, I tried to build the git version with a simple cmake .. + make -j1, while the Debian package passes some extra flags. Please let me know if any other info is needed.
Please also note that I don't have any knowledge about this software, I'm just trying to make sure the Debian package is not broken (as it's a dep for telegram-desktop).

[VictorEijkhout]

gcc 14 on other platforms fails too.

/work/00434/eijkhout/rangev3/rangev3-0.12.0/test/constexpr_core.cpp:63:38: error: no type named ‘type’ in ‘struct concepts::common_reference<const ForwardIterator<const int*, false>&, const ForwardIterator<const int*, false>&>’
   63 |     if (ranges::iter_distance_compare(beg, last, 5) != -1) { return false; }
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
/work/00434/eijkhout/rangev3/rangev3-0.12.0/test/test_iterators.hpp: At global scope:
/work/00434/eijkhout/rangev3/rangev3-0.12.0/test/test_iterators.hpp:173:17: error: inline function ‘constexpr bool operator!=(const InputIterator<int*>&, const InputIterator<int*>&)’ used but never defined [-Werror]
  173 |     friend bool operator!=(const InputIterator& x, const InputIterator& y)
      |                 ^~~~~~~~

I fear that this product is abandonware.

[wRAR]

It has recent commits though...

[brevzin]

The first problem reduces to this:

#include <type_traits>
int main() { }

which fails to compile with g++-14 -std=c++14 -fconcepts, as you can see here.

I don't think there's anything we can do here to fix it, you can complain to gcc?

[brevzin]

That passes on gcc trunk now, so maybe it'll start building with gcc 14.3.

[wRAR]

(note that this isn't related to my problem which still happens on sid where that simple example compiles fine)

[brevzin]

Here's a repro for that one. It appears that gcc 13 and then 14 broke (in different ways) how -std=c++14 -fconcepts works:

#if (defined(__cpp_concepts) && __cpp_concepts > 0)
#if __cpp_concepts <= 201507L
#define META_CONCEPT concept bool
#define META_TYPE_CONSTRAINT(...) typename
#else
#define META_CONCEPT concept
#define META_TYPE_CONSTRAINT(...) __VA_ARGS__
#endif  
#else   
#define META_TYPE_CONSTRAINT(...) typename
#endif 

// gcc 13 rejects this because of concept bool
template <typename T>
META_CONCEPT invocable = true;

// gcc 14 rejects this because of invocable F
template <META_TYPE_CONSTRAINT(invocable) F, typename L>
struct apply;

[jwakely]

With GCC 13, -std=c++14 -fconcepts defines __cpp_concepts to 201507L, because not all of C++20 concepts are supported. But it's also not really the concepts TS support either (you should use -fconcepts-ts for that in GCC 13). So concept bool isn't valid, because that's a feature of the TS not C++20 concepts, and you asked for C++20 concepts. That was a change since GCC 12, which (incorrectly, IMHO) accepted concept bool when using -fconcepts.

With GCC 14, it looks like -std=c++14 -fconcepts now defines a later value for __cpp_concepts, which causes Barry's reduced test to try to use a constraint like template<invocable F>, but that isn't valid in C++14 mode, and I don't think we (GCC) care about supporting that combination. That invocable constraint would not have worked in C++14 mode in GCC 12 or GCC 13 either, it's just that the preprocessor logic meant it was never even attempted, because of the lower __cpp_concepts value.

Maybe in addition to checking __cpp_concepts, range-v3 should also test that __cplusplus >= 201703L before trying to use constrained declarations.

[jicama]

I don't think there's anything we can do here to fix it, you can complain to gcc?

This is already fixed on the G++ 14 branch. But mostly this is convincing me that we should stop allowing -std=c++14 -fconcepts at all.

[CaseyCarter]

I don't think there's anything we can do here to fix it, you can complain to gcc?

This is already fixed on the G++ 14 branch. But mostly this is convincing me that we should stop allowing -std=c++14 -fconcepts at all.

Dropping in from lurking to say that I was thinking the same thing but from range-v3's point of view: we should drop support for TS concepts altogether.

[jicama]

FYI I've now adjusted 13, 14, and trunk to not define __cpp_concepts at all for -std=c++14 -fconcepts.