Closed
Description
// A.cppm
module;
#include <ranges>
export module A;
// B.cppm
module;
#include <ranges>
export module B;
import A;
clang++ -fprebuilt-module-path=. -std=c++20 --precompile A.cppm -o A.pcm
clang++ -fprebuilt-module-path=. -std=c++20 --precompile B.cppm -o B.pcm
Compilation of the second file results in several errors like this
In module 'A' imported from B.cppm:6:
/usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/ranges:1258:2: error: 'std::ranges::views::_All::operator()' from module 'A.<global>' is not present in definition of 'std::ranges::views::_All' provided earlier
operator() [[nodiscard]] (_Range&& __r) const
^
/usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/12.2.1/../../../../include/c++/12.2.1/ranges:1258:2: note: declaration of 'operator()' does not match
operator() [[nodiscard]] (_Range&& __r) const
^
This is using Clang trunk and libstdc++ that is distributed with GCC 12.2.1.
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
llvmbot commentedon Mar 10, 2023
@llvm/issue-subscribers-clang-modules
ChuanqiXu9 commentedon Mar 10, 2023
Thanks for reporting this! Would you like to reduce the defect report? It will be pretty helpful.
We can reduce the defect report by:
<ranges>
to a local headermy_ranges
.my_ranges
in the reproducer.my_ranges
until we can't make it any more.camio commentedon Mar 11, 2023
This reduced version reproduces the issue.
The issue seems to be related to the deduction guide. If the requires clause is changed to
Foo<T>{T()};
, the issue appears to go away.davidstone commentedon Mar 11, 2023
This feels a lot like #60486. Note in particular "The practical effect of this bug is that
#include <ranges>
fails when used in two modules with libstdc++."camio commentedon Mar 14, 2023
Thank you!
Removed ranges-fix since it is no longer needed
[C++20] [Modules] Profile TemplateName by canonical decl
[C++20] [Modules] Profile TemplateName by canonical decl
mizvekov commentedon Jun 12, 2024
I have come across this change while working on another problem.
The fix which was committed is not correct : The profile function is supposed to support structural comparison, not referential comparison. It's even inconsistent that it would arbitrarily pick referential comparisons for 'TemplateDecl' names, but pick structural for everything else.
This can't be the real solution: When we build canonical types, we start with canonical components, and profiling these still does the right thing, because for canonical stuff, structural and referential comparisons are equivalent.
This fix causes issues where TemplateNames would become canonicalized on the first spelling appearing in source, and their spellings in diagnostics becoming inconsistent.
For example, some libcxx tests emitting diagnostics with different spellings depending on whether they were built with modules or not.
8 remaining items