llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.87k stars 11.93k forks source link

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

Open ncihnegn opened 4 months ago

ncihnegn commented 4 months ago

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

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 commented 4 months ago

@llvm/issue-subscribers-clang-modules

Author: None (ncihnegn)

clang version 19.0.0git (https://github.com/llvm/llvm-project 5220b7bea8b01f46e9f7326b9c9a7e550e8451d1) ``` 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.
ChuanqiXu9 commented 4 months ago

This may be a different issue than https://github.com/llvm/llvm-project/issues/91111. Since that one is complaining redefinition of concept and this one is about different requires clause.

ChuanqiXu9 commented 4 months ago

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 https://github.com/llvm/llvm-project/issues/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 commented 4 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

ChuanqiXu9 commented 1 month ago

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.