Compilation failure with piped ranges in range::v3 for_each and nvc++/22.11

[pseyfert]

It has occured to me that the following code doesn’t compile with nvc++ while g++ is happy with it

    ranges::for_each(
        ranges::getlines(in_stream) | ranges::view::transform([](auto line) {
            return ranges::size(line);
        }),
        [&v](auto size) { v.push_back(size); });

(please find a more complete example here Compiler Explorer … it’s not very creative, it counts the number of lines in for_each.hpp by determining the lengths of all lines in the file and then ignore the results and report how many lines were counted)

I suspect it’s something around the construct for_each( getlines | other_view, … ) because as you can see in the comment, for_each(getlines, … ) is accepted. (This also means I have a workaround by just pushing all pipe logic into the lambda).

From the error it’s not entirely clear to me what goes wrong and if my code shouldn’t compile or if the error is on the side of range v3 or nvc++, but i thought i should let you know.

Cheers,
Paul

[MatColgrove]

Hi Paul,

The error appears to be coming from line 821 of “range-v3/include/concepts/concepts.hpp” (as cloned from GitHub - ericniebler/range-v3: Range library for C++14/17/20, basis for C++20's std::ranges).

#if defined(__clang__) || defined(_MSC_VER)`
    template<bool B>`
    std::enable_if_t<B> requires_()`
    {}`
#else`
    template<bool B>`
    CPP_INLINE_VAR constexpr std::enable_if_t<B, int> requires_ = 0;   /// <<< Error is here`
#endif`

With the work around being to have nvc++ take the same path as Clang:

#if defined(__clang__) || defined(_MSC_VER) || defined(__NVCOMPILER)
    template<bool B>
    std::enable_if_t<B> requires_()
    {}
#else
    template<bool B>
    CPP_INLINE_VAR constexpr std::enable_if_t<B, int> requires_ = 0;
#endif

I talked with one of our C++ engineers and he believes nvc++ should be giving an error as “requires_” is being declared as a variable rather than a function. Though, he’s not confident in the answer nor can easily explain why g++ accepts it, but unfortunately doesn’t does have the time right now to dig into it.

-Mat

[ericniebler]

Thanks Mat. I went ahead and made that suggested change upstream.

Eric

[pseyfert]

Hi Mat and Eric,

I cherry-picked the commit and it fixes the compilation of the code from which I derived the example.

Thanks for the quick fix.
Paul