-
Notifications
You must be signed in to change notification settings - Fork 11.9k
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
Error when importing <string> and <iostream> in same file with c++-20 standard modules #58540
Comments
@llvm/issue-subscribers-clang-modules |
@mls-m5 While it is not a proper solution, a workaround is changing The workaround works because without naming the modules the This seems to be another example of an known issue where we need explicit template deduction guides in
I'll try to come up with a fix. |
Ok thanks for the response, and thanks for the workaround. One wierd problem I noticed with using the syntax # Paths are a litle bit different when i run, I leave them in if they are the problem.
clang++-16 -std=c++20 -stdlib=libc++ -xc++-system-header --precompile iostream -o "build/.mm3/default/iostream.pcm" -Wno-pragma-system-header-outside-header -Wno-user-defined-literals
clang++-16 -std=c++20 -stdlib=libc++ "apa.cpp" -fmodule-file="<iostream>=build/.mm3/default/iostream.pcm" -c -o "build/.mm3/default/apa.o"
apa.cpp:6:8: error: header file <iostream> (aka '/usr/lib/llvm-16/bin/../include/c++/v1/iostream') cannot be imported because it is not known to be a header unit
import <iostream>;
^
apa.cpp:10:5: error: use of undeclared identifier 'std'
std::cout << "hello" << std::endl;
^
apa.cpp:10:29: error: use of undeclared identifier 'std'
std::cout << "hello" << std::endl;
^
apa.cpp:11:5: error: use of undeclared identifier 'std'
std::string str = "satnhoeu";
^
4 errors generated.
It seems likei will have to handle dependencies differently if I include or when i import. (Maybe a separate issue, but I thought it should work.) Code used in that experiment import <iostream>;
int print() {
std::cout << "hello" << std::endl;
std::string str = "satnhoeu";
return 10;
} |
I assigned myself to add this one to my TODO list. But to be honest, I prefer named modules than header units so the priority of this task is relatively low to me. (I have many TODOs...) So if any one want to look at this, feel free to take it. |
I did not realize before now that |
Started using clang++16 and update my module knowledge and compile with matmake3 * Started using clang++-16 not finished yet * Experiments to solve problems with gl functions * It compiles * Workaround for clang bug that prevents importing string and iostream Described here llvm/llvm-project#58540 https://stackoverflow.com/questions/74149849/error-when-importing-string-and-iostream-in-same-file?noredirect=1#comment130924685_74149849 * Restructure draw shaderprogram and remove namespace obj * Fix to clang-related issue * First actual working build with matmake3 and real modules with clang * Replace include statements with import statements * Remove old broken code * Update CI workflow
Does this have anything to do with libc++? If not, I think we should remove the tag. |
No, almost of the header units issues should be unrelated to the standard libraries. Since the intention of header units is to import existing and old libraries. So it is meaningless to me that we need to refactor the current header to make it importable for header units. |
I get a compilation error when trying to import
<string>
and<iostream>
in the same file. Something seems to be off.This is what I have tried this far. (based on instructions from clang)
Note that it compiles when I remove the line
std::cout << "hello" << std::endl;
Also: When just importing
<iostream>
it seems to work, so that might be a possible temporary workaround, andiostream
seems to definestd::string
. I don't think it's standard but it kind of works until the bug is fixed. Like this:The error message I get is
I have also tried to compile the header units with
But get the same result
The text was updated successfully, but these errors were encountered: