std module before include <iterator> will have a "requires clause differs in template redeclaration" error

[ncihnegn]

clang version 19.0.0git (https://github.com/llvm/llvm-project 5220b7b)

import std;

#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include <doctest/doctest.h>

TEST_CASE("") {
  CHECK_EQ(1, 0);
}

[1/10] Scanning /usr/local/Sither/Cellar/llvm/5220b7bea/share/libc++/v1/std.compat.cppm for CXX dependencies
[2/10] Scanning /Users/Temp/playground/c++-std-modules/main.cpp for CXX dependencies
[3/10] Scanning /usr/local/Sither/Cellar/llvm/5220b7bea/share/libc++/v1/std.cppm for CXX dependencies
[4/10] Generating CXX dyndep file CMakeFiles/__cmake_cxx26.dir/CXX.dd
[5/10] Generating CXX dyndep file CMakeFiles/main.dir/CXX.dd
[6/10] Building CXX object CMakeFiles/__cmake_cxx26.dir/usr/local/Sither/Cellar/llvm/5220b7bea/share/libc++/v1/std.cppm.o
[7/10] Building CXX object CMakeFiles/__cmake_cxx26.dir/usr/local/Sither/Cellar/llvm/5220b7bea/share/libc++/v1/std.compat.cppm.o
[8/10] Linking CXX static library lib__cmake_cxx26.a
[9/10] Building CXX object CMakeFiles/main.dir/main.cpp.o
FAILED: CMakeFiles/main.dir/main.cpp.o
/usr/local/opt/llvm/bin/clang++  -I/Users/Temp/playground/c++-std-modules/_build/_deps/doctest-src -g -std=gnu++26 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk -MD -MT CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d @CMakeFiles/main.dir/main.cpp.o.modmap -o CMakeFiles/main.dir/main.cpp.o -c /Users/Temp/playground/c++-std-modules/main.cpp
In file included from /Users/Temp/playground/c++-std-modules/main.cpp:4:
In file included from /Users/Temp/playground/c++-std-modules/_build/_deps/doctest-src/doctest/doctest.h:514:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/ostream:176:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__ostream/basic_ostream.h:14:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__memory/shared_ptr.h:31:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__memory/uninitialized_algorithms.h:13:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__algorithm/copy.h:12:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__algorithm/copy_move_common.h:12:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__algorithm/iterator_operations.h:13:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__algorithm/ranges_iterator_concept.h:13:
/usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__iterator/concepts.h:222:11: error: requires clause differs in template redeclaration
  222 |   requires(indirectly_readable<_Its> && ...) && invocable<_Fp, iter_reference_t<_Its>...>
      |           ^
/usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__iterator/concepts.h:222:11: note: previous template declaration is here
  222 |   requires(indirectly_readable<_Its> && ...) && invocable<_Fp, iter_reference_t<_Its>...>
      |           ^
1 error generated.
ninja: build stopped: subcommand failed.

Similar to #91111.

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: None (ncihnegn)

clang version 19.0.0git (https://github.com/llvm/llvm-project 5220b7b) ``` import std;

#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include <doctest/doctest.h>

TEST_CASE("") {
CHECK_EQ(1, 0);
}

[1/10] Scanning /usr/local/Sither/Cellar/llvm/5220b7bea/share/libc++/v1/std.compat.cppm for CXX dependencies
[2/10] Scanning /Users/Temp/playground/c++-std-modules/main.cpp for CXX dependencies
[3/10] Scanning /usr/local/Sither/Cellar/llvm/5220b7bea/share/libc++/v1/std.cppm for CXX dependencies
[4/10] Generating CXX dyndep file CMakeFiles/__cmake_cxx26.dir/CXX.dd
[5/10] Generating CXX dyndep file CMakeFiles/main.dir/CXX.dd
[6/10] Building CXX object CMakeFiles/__cmake_cxx26.dir/usr/local/Sither/Cellar/llvm/5220b7bea/share/libc++/v1/std.cppm.o
[7/10] Building CXX object CMakeFiles/__cmake_cxx26.dir/usr/local/Sither/Cellar/llvm/5220b7bea/share/libc++/v1/std.compat.cppm.o
[8/10] Linking CXX static library lib__cmake_cxx26.a
[9/10] Building CXX object CMakeFiles/main.dir/main.cpp.o
FAILED: CMakeFiles/main.dir/main.cpp.o
/usr/local/opt/llvm/bin/clang++ -I/Users/Temp/playground/c++-std-modules/_build/_deps/doctest-src -g -std=gnu++26 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.5.sdk -MD -MT CMakeFiles/main.dir/main.cpp.o -MF CMakeFiles/main.dir/main.cpp.o.d @CMakeFiles/main.dir/main.cpp.o.modmap -o CMakeFiles/main.dir/main.cpp.o -c /Users/Temp/playground/c++-std-modules/main.cpp
In file included from /Users/Temp/playground/c++-std-modules/main.cpp:4:
In file included from /Users/Temp/playground/c++-std-modules/_build/_deps/doctest-src/doctest/doctest.h:514:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/ostream:176:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__ostream/basic_ostream.h:14:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__memory/shared_ptr.h:31:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__memory/uninitialized_algorithms.h:13:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__algorithm/copy.h:12:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__algorithm/copy_move_common.h:12:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__algorithm/iterator_operations.h:13:
In file included from /usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__algorithm/ranges_iterator_concept.h:13:
/usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__iterator/concepts.h:222:11: error: requires clause differs in template redeclaration
222 | requires(indirectly_readable<_Its> && ...) && invocable<_Fp, iter_reference_t<_Its>...>
| ^
/usr/local/Sither/Cellar/llvm/5220b7bea/bin/../include/c++/v1/__iterator/concepts.h:222:11: note: previous template declaration is here
222 | requires(indirectly_readable<_Its> && ...) && invocable<_Fp, iter_reference_t<_Its>...>
| ^
1 error generated.
ninja: build stopped: subcommand failed.

Similar to #<!-- -->91111.
</details>

[ChuanqiXu9]

This may be a different issue than #91111. Since that one is complaining redefinition of concept and this one is about different requires clause.

[ChuanqiXu9]

I didn't run the reproducer provided by the OP. But construct a similar one:

import std;
#include <iterator>

And the analysis shows, it might be a library issue instead of a compiler issue.

The compiler are complaining about the inconsistent definition from the module and the main file.

template <class _Fp, class... _Its>
  requires(indirectly_readable<_Its> && ...) && invocable<_Fp, iter_reference_t<_Its>...>
using indirect_result_t = invoke_result_t<_Fp, iter_reference_t<_Its>...>;

When I look into the issue, I found the AST in the module file shows the && used here is the trivial && operator but the && operator used in main file is a call expr. Then I remember #61643 which is also problematic due to the free standing operator &&.

Then I tried to comment out using std::operator&& in valarray.inc. And it compiles. Now we can explain the reproducer, when the compiler compile #include <iterator> in the main file, the operator && in std module is visible to the current module, then the require clause for indirect_result_t have a different meaning in the mainfile and so the compiler complains.

CC: @mordante

And if we can't solve the problem quickly, I think it may be helpful to comment out using std::operator&& and using std::operator|| in valarray.inc before clang19. I feel valarray is relatively rarely used.

[mordante]

I can reproduce @ChuanqiXu9's reproducer. It seems only <valarray> exports std::operator&& and std::operator||. I agree valarray is rarely used; otherwise there would be more bugreports for this header :-(.

I still prefer to look at a real bug-fix. But having a libc++-19 "hack" doesn't sound too bad; modules are still considered experimental in libc++ and that won't change in LLVM-19.

[mordante]

I tested and it seems more failures occur. __synth_three_way which IIRC we recently made a lambda again. So I feel a bit reluctant to change this behaviour. We don't have good tests to see what else might break. I think we really should look at a way how libc++ headers and the std module are compatible. @ChuanqiXu9 we talked about that a while ago, maybe we should restart that discussion.

[ChuanqiXu9]

I tested and it seems more failures occur. __synth_three_way which IIRC we recently made a lambda again. So I feel a bit reluctant to change this behaviour. We don't have good tests to see what else might break. I think we really should look at a way how libc++ headers and the std module are compatible. @ChuanqiXu9 we talked about that a while ago, maybe we should restart that discussion.

Yeah, given that is a separate issue. Let's talk somewhere else. Maybe discord or another issue. From the perspective of software engineering, I feel it will be better to have more test on this.

[mordante]

Discord is fine. I agree we should have more tests, however there are some concerns of other libc++ developers about adding module tests since they need modifications to existing tests.

[ldionne]

Removing from the 19 milestone since it seems this is slipping to the next release.

[ChuanqiXu9]

I tested and it seems more failures occur. __synth_three_way which IIRC we recently made a lambda again.

This may be fixed. Can you try again?

We don't have good tests to see what else might break. I think we really should look at a way how libc++ headers and the std module are compatible. @ChuanqiXu9 we talked about that a while ago, maybe we should restart that discussion.

Oh, I forgot this. Sorry. I hope we can have more tests. But I remember the reason we didn't do this is due to that we don't want this test bring more testing pressure on libc++ folks. So maybe it is better to add a few tests that won't bring you more trouble if possible.