-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
modules: ambiguous call to overloaded function #4090
Comments
I observe that this works if I replace |
Slightly reduced:
export module Core;
export import std;
module;
export module Timer;
#ifdef WORKAROUND
import std;
#else
import <chrono>;
#endif
export {
std::string GetTimeStamp() {
const auto now = std::chrono::system_clock::now();
const auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch());
return std::to_string(ms.count());
}
}
module;
export module Logger;
import Core;
import Timer;
export void PrintMessage(const std::string& message) {
std::println("{}: {}", GetTimeStamp(), message);
}
export module App;
import Logger;
export struct App {
static void Start() {
PrintMessage("Start");
}
static void Stop() {
PrintMessage("Stop");
}
};
import App;
import Logger;
int main() {
App::Start();
PrintMessage("Hello C++ Modules!");
App::Stop();
}
|
You state "At this time, if you use the std module, you should do so consistently throughout your project." |
Mixing named modules and classic includes or header units within a single TU is super doomed due to the compiler bug/limitation. Consistent TUs being mixed together during linking is probably still doomed but I haven't checked. The compiler team mentioned something about the linker having a fallback to deal with what happens when it sees strong ownership being mixed with classic compilation (I think those words make sense in that order) but that didn't seem to be my experience when I was initially updating the STL to make Sorry I can't be more precise (I don't have sufficient time right now to explore the limits of this compiler limitation since there's nothing actionable for the STL). |
Hello again, I started the project from scratch, so I can focus on solely using modules, either way, it doesn't seem to be restricted to mixing modules with includes. The issue also arises when exclusively using modules in a larger project.. I tried to track down the issue, but again, it proved impossible. I am using the latest Visual Studio 2022 17.9.0 Preview 2.1. It happens if I simply add a string to a struct, there is nothing crazy going on behind, but I think the crucial part is, having a large project. As I said I started from scratch, created a lot of empty modules and so on, the most of them are empty and planned to be used in future. Here's the line (GitHub) that triggers the following error:
I tried solely
I am not sure if it will be helpful, but I uploaded the intermediate files in case they can help identify the problem. |
Hmm, I've found the culprit; it was a third-party import of a header unit. However, I found an alternative, 'Bridges,' in this DevBlog that helps me move forward. Nevertheless, thank you guys for your great work! |
same issue here. #include <some standard header>
import std; would always report |
This should work according to the Change-Log after the 19.10 Preview 1. But only in that order as you posted it. Using a header after the import would also break the build. I am waiting since november to be able to use this, cause it was quickly fixed internally (look at discord), but we the community have to wait months until Microsoft releases this compiler fix to the public, which is realy unfortunate. I hope that Microsoft gets a change of heart and open sources the compiler some day, so that things can get really fast. It's really a shame, cause their compiler is the best one for modules right now, but also has a lot of issues around them, and sadly it's 2024. |
Yep, I've verified that #4154 in VS 2022 17.10 Preview 1 has fixed this scenario. I can now successfully build the repro (with 17.10 Preview 4):
|
Describe the bug
As it seems there is a bug if you use
export import std;
in one module, than for exampleimport <chrono>;
in another. Now if you import these two modules in a third one, you get various errors depending on the used header unit in the second. I tried it with 'string', 'chrono' and 'print', but it seems that it doesn't matter which one I use.Expected behavior
I'm not sure, I tried reimporting my modules, and the compiler doesn't seem to complain, so I think there should be no problem at all if you reimport std, or a header unit which it contains. I mean also with headers there was never such thing, thanks to '#pragma once'.
STL version
Additional context
I created a small project to reproduce this bug.
Test.zip
The text was updated successfully, but these errors were encountered: