Error with C++ modules: not present in definition provided earlier

[rnikander]

Here is a boiled down version of something happening in a real project.

Mod1.cc

module;
#include <ranges>
export module Mod1;

Mod2.cc

module;
#include <iterator>
#include <valarray>
#include <ranges>
export module Mod2;
import Mod1;

build.sh

CXX="/Users/rob/Dev/llvm-project/build/bin/clang++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -std=c++2b"
set -e
$CXX -fprebuilt-module-path=. -x c++-module Mod1.cc --precompile -o Mod1.pcm
$CXX -fprebuilt-module-path=. -x c++-module Mod2.cc --precompile -o Mod2.pcm

Errors:

In module 'Mod1' imported from Mod2.cc:6:
/llvm-project/build/bin/../include/c++/v1/__ranges/zip_view.h:494:40: error: 'std::__1::ranges::views::__zip::__fn::operator()' from module 'Mod1.<global>' is not present in definition of 'std::__1::ranges::views::__zip::__fn' provided earlier
  _LIBCPP_HIDE_FROM_ABI constexpr auto operator()(_Ranges&&... __rs) const
                                       ^
/llvm-project/build/bin/../include/c++/v1/__ranges/zip_view.h:491:40: note: declaration of 'operator()' does not match
  _LIBCPP_HIDE_FROM_ABI constexpr auto operator()() const noexcept { return empty_view<tuple<>>{}; }
                                       ^
/llvm-project/build/bin/../include/c++/v1/__ranges/zip_view.h:494:40: note: declaration of 'operator()' does not match
  _LIBCPP_HIDE_FROM_ABI constexpr auto operator()(_Ranges&&... __rs) const
                                       ^
1 error generated.

[ChuanqiXu9]

Could you try it again after you remove the line #include <valarray>? I guess it may related to #61150. Since I met similar problem for:

module;
#include <variant>
export module a;

//

module;
#include <valarray>
#include <variant>
export module b;
import a;

Then the conclusion is that the operator in <valarray> pollutes the definition in <variant>.

[llvmbot]

@llvm/issue-subscribers-clang-modules

[rnikander]

Yes, <valarray> triggers the error, and without that everything seems fine. I left the <iterator> because that causes it to give the same error message that I was getting in my real program.

[ChuanqiXu9]

So if I understand correctly, this is not a compiler bug. It is an existing defect that <valarray> shouldn't define the operator which may pollute the namespace.

[rnikander]

So if I understand correctly, this is not a compiler bug. It is an existing defect that <valarray> shouldn't define the operator which may pollute the namespace.

What operator is valarray defining that does this? How does it step on std::ranges::views::__zip ?

Are you saying this is a known bug in libc++? I'm confused because it was closed as invalid, not a duplicate. It sure seems like a bug in something. I got a cryptic error and had to randomly mess with #include order until it went away.

[ChuanqiXu9]

So if I understand correctly, this is not a compiler bug. It is an existing defect that <valarray> shouldn't define the operator which may pollute the namespace.

What operator is valarray defining that does this? How does it step on std::ranges::views::__zip ?

Are you saying this is a known bug in libc++? I'm confused because it was closed as invalid, not a duplicate. It sure seems like a bug in something. I got a cryptic error and had to randomly mess with #include order until it went away.

Sorry for the confusion. The invalid tag was added automatically. I wanted to create a new issue "possible problems if we include " just like I did in #61465. I mean this can help people to be less confused. But maybe I close it too quickly indeed. I'll reopen this one until I make the new issue.

What operator is valarray defining that does this? How does it step on std::ranges::views::__zip ?

I am not 100% sure for the case. But for the above variant case I mentioned, it was reduced to #61150, so that the operator&& is the problem. It makes the operator && in the require clause different in different TU. And for your case, I guess it may cause problem here:

// zip_view.h
template <input_range... _Views>
  requires(view<_Views> && ...) && (sizeof...(_Views) > 0)
class zip_view : public view_interface<zip_view<_Views...>> {

The && may be impacted by the operator&& in valarray. But I need to investigate more to be sure.

Are you saying this is a known bug in libc++?

I am not 100% sure now. It is also possible that the compiler didn't do well for concepts or the standard doesn't make it clear.

In our downstream, we remove the use of <valarray> temporarily. And for your case, if you can't make that, I think it may workaround your problem by including <valarray> in front of #include <ranges> in the Mod1

[mordante]

@ChuanqiXu9 I came to the same conclusion, commenting out all 3 operator&& overloads in valarray "solves" this bug.

[ChuanqiXu9]

Let's track the issue in #61643

[ChuanqiXu9]

@ChuanqiXu9 I came to the same conclusion, commenting out all 3 operator&& overloads in valarray "solves" this bug.

(Let's reply again in #61643)

Yeah, but it is not the "proper" solution clearly... I am wondering if this is a standard defect and wondering if I should send this to LEWG.