Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

path is not implicitly constructible from UTF-8, UTF-16 or UTF-32 literals #119

Closed
zero9178 opened this issue May 1, 2021 · 3 comments
Closed
Assignees
Labels
available on master Fix is done on master branch, issue closed on next release bug Something isn't working
Milestone

Comments

@zero9178
Copy link
Contributor

zero9178 commented May 1, 2021

Implementations of std::filesystem I have tested (libc++, libstdc++ and MSVC STL) all support the use of u8, u16 and u32 string literals to construct a path using constructor 5 described here in cppreference: https://en.cppreference.com/w/cpp/filesystem/path/path

The relevant standard text is https://eel.is/c++draft/fs.path.type.cvt I believe, though I am not well versed in the C++ Standard.

I encountered this issue with the following code:

#include <filesystem>

int main()
{
    ghc::filesystem::exists(u8"test");
}

which failed to compile in C++20 mode when I was using either Clang 12 or GCC 11 (on Windows). I believe it should also be reproducible using UTF-16 or UTF-32 literals in C++17 mode.

The same code in CE, showing all 3 STL implementations compiling the above:
https://godbolt.org/z/Gd835xxGv

@gulrak gulrak self-assigned this May 1, 2021
@gulrak gulrak added the bug Something isn't working label May 1, 2021
@gulrak gulrak added this to the v1.5.6 milestone May 1, 2021
@gulrak
Copy link
Owner

gulrak commented May 1, 2021

Indeed, that should work while compiling with C++20 mode, and I can reproduce the issue.
Thanks for reporting, I'll look into it.

@gulrak
Copy link
Owner

gulrak commented May 2, 2021

With the fix from branch feature-119-support-u8-u16-u32-literals it works for me now. (But I don't have Clang 12 or GCC 11 on Windows at hand, tested on macOS with Clang and Windows with VS2019.)

@zero9178
Copy link
Contributor Author

zero9178 commented May 2, 2021

Just checked out the branch and ran your whole testsuite against both toolchains and can happily confirm that it's working and that there are no regressions either.

@gulrak gulrak added the available on master Fix is done on master branch, issue closed on next release label May 2, 2021
@zero9178 zero9178 closed this as completed May 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
available on master Fix is done on master branch, issue closed on next release bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants