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

Can't use UDL of std::string with import std; #72427

Closed
JohelEGP opened this issue Nov 15, 2023 · 5 comments · Fixed by #75000
Closed

Can't use UDL of std::string with import std; #72427

JohelEGP opened this issue Nov 15, 2023 · 5 comments · Fixed by #75000
Assignees
Labels
clang:modules C++20 modules and Clang Header Modules libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.

Comments

@JohelEGP
Copy link

With https://libcxx.llvm.org/Modules.html#using-in-external-projects,
the following program fails:

export module main;
import std;
using namespace std::string_literals;
main.cpp:3:22: error: missing '#include <string>'; 'string_literals' must be declared before it is used
    3 | using namespace std::string_literals;
      |                      ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/string:4387:20: note: declaration here is not visible
 4387 |   inline namespace string_literals
      |                    ^
1 error generated.
@EugeneZelenko EugeneZelenko added clang:modules C++20 modules and Clang Header Modules and removed new issue labels Nov 15, 2023
@llvmbot
Copy link
Collaborator

llvmbot commented Nov 15, 2023

@llvm/issue-subscribers-clang-modules

Author: Johel Ernesto Guerrero Peña (JohelEGP)

With <https://libcxx.llvm.org/Modules.html#using-in-external-projects>, the following program fails: ```C++ export module main; import std; using namespace std::string_literals; ``` ``` main.cpp:3:22: error: missing '#include <string>'; 'string_literals' must be declared before it is used 3 | using namespace std::string_literals; | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/string:4387:20: note: declaration here is not visible 4387 | inline namespace string_literals | ^ 1 error generated. ```

@ChuanqiXu9 ChuanqiXu9 added the libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi. label Nov 16, 2023
@ChuanqiXu9
Copy link
Member

I am wondering if this is a libc++'s issue. I've checked that in modules/std/string.inc, only the namespace std::literals and std::literals::string_literals are exported and std::string_literals are not mentioned. @mordante

@JohelEGP
Copy link
Author

using namespace std::literals::string_literals; fails equally.

@ChuanqiXu9
Copy link
Member

using namespace std::literals::string_literals; fails equally.

Got it. I'll try to take a look.

@ChuanqiXu9
Copy link
Member

ChuanqiXu9 commented Nov 16, 2023

After I took more experiment in the library level, I feel this is a library issue more.

First, it is not a problem to using namespace std::literals;. Since there are multiple use inline namespace literals inside *.inc under build/_deps/std-src/std.

Then for std::literals::string_literals, it is guarded by #if directives in string.inc:

// TODO MODULES is this a bug?
#if _LIBCPP_STD_VER >= 23
  using std::operator""s;
#else
  inline namespace literals {
    inline namespace string_literals {
      // [basic.string.literals], suffix for basic_string literals
      using std::literals::string_literals::operator""s;
    } // namespace string_literals
  }   // namespace literals
#endif

It looks like the #else branch is not taken since I added an #error directive but the std module still compiles.

Finally, I add the namespaces manually in string.inc:

inline namespace literals {
    inline namespace string_literals {}
  }

Then using std::literals::string_literals; compiles too.

For std::string_literals, since it doesn't appear in any place under build/_deps/std-src/std, so I believe it is not exported.

@mordante mordante self-assigned this Nov 16, 2023
mordante added a commit to mordante/llvm-project that referenced this issue Dec 12, 2023
The fix changes the way the validation script determines the qualified
name of a declaration. Inline namespaces without a reserved name are now
always part of the name. The Clang code only does this when the names
are ambigious. This method is often used for the operator""foo for UDLs.

Adjusted the newly flagged issue and removed a work-around in the test
code that is no longer required.

Fixes llvm#72427
mordante added a commit that referenced this issue Dec 12, 2023
The fix changes the way the validation script determines the qualified
name of a declaration. Inline namespaces without a reserved name are now
always part of the name. The Clang code only does this when the names
are ambigious. This method is often used for the operator""foo for UDLs.

Adjusted the newly flagged issue and removed a work-around in the test
code that is no longer required.

Fixes #72427
blueboxd pushed a commit to blueboxd/libcxx that referenced this issue Feb 1, 2024
The fix changes the way the validation script determines the qualified
name of a declaration. Inline namespaces without a reserved name are now
always part of the name. The Clang code only does this when the names
are ambigious. This method is often used for the operator""foo for UDLs.

Adjusted the newly flagged issue and removed a work-around in the test
code that is no longer required.

Fixes llvm/llvm-project#72427

NOKEYCHECK=True
GitOrigin-RevId: 7d34f8c09ee17327668c337ff3a7c30656f8daca
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:modules C++20 modules and Clang Header Modules libc++ libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants