Open rnikander opened 1 year ago
Could this be an issue with #include
orders or is it a missing macro/concept or some other defintion somewhere? I had an issue with #include<memory>
needing to be included before #include<filesystem>
. Maybe there is something similar happening here.
I do confirm that I get the same error and only when using modules. Navigating the traceback, I don't see anything that should be creating such an issue. I find it weird because when I replace template<>static void unescape(StringType& s)
with an explicit static void unescape(std::string& s)
the problem does not manifest. I have tried moving around the code, but that makes no difference. I have even tested with static_assert(std::same_as<string_t,std::string>);
and that does not fail. This could be a clang bug if you can rope some of them to take a look at this.
Description
I'm not sure if this is a bug in Clang, or in this library. I've been using C++20 modules there but they do have some problems.
https://godbolt.org/z/ndqTvEzGj
I linked to Clang 16.0.0, because as of right now, the trunk is segfaulting. It's been doing that for a few days now. But normally I use Clang trunk when I can.
Reproduction steps
Look at the godbolt example, it shows the error. It's a minimal example with no other code in the files.
Expected vs. actual results
This cryptic compiler error shouldn't be happening.
Minimal code example
Error messages
Compiler and operating system
linux, clang, or macos clang
Library version
6af826d0bdb55e4b69e3ad817576745335f243ca via conan
Validation
develop
branch is used.