Open wRAR opened 3 months ago
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.
It has recent commits though...
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?
That passes on gcc trunk now, so maybe it'll start building with gcc 14.3.
(note that this isn't related to my problem which still happens on sid where that simple example compiles fine)
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;
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.
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.
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.
FYI I've now adjusted 13, 14, and trunk to not define __cpp_concepts at all for -std=c++14 -fconcepts.
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:
(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).