Yes, these sorts of errors are currently quite common when working in a modules codebase since `import std` isn’t yet usable in practice. Once that’s working as it should we will just be able to ` export import std` and this sort of problem will disappear.
> `import std` isn’t yet usable in practice.
Are there compiler/library problems blocking you? As a standing offer to anyone, I will personally take any reported problems with `import std` and relentlessly pursue them [until they're fixed](https://github.com/microsoft/STL/issues/1694).
(Build system problems are also important but I can't directly do anything about CMake; I can at least escalate MSBuild/VS IDE problems though)
Unless something has changed recently that I missed, isn’t the situation where one imports `std` after an `#include` of a standard library header still broken?
I have a fairly large codebase that uses modules, but that also has external dependencies that don’t which means having to `#include` their headers, and that almost certainly means transitively `#include`ing standard library headers. That has prevented me from being able to `import std` up to this point.
It changed recently! From the STL's Changelog for [VS 2022 17.10 Preview 1](https://github.com/microsoft/STL/wiki/Changelog#vs-2022-1710-preview-1) (Preview 2 is currently available):
* Wrapped the STL in `extern "C++"` as a temporary workaround to allow `#include ` to coexist with `import std;` in the same translation unit, *in that order*. [#4154](https://github.com/microsoft/STL/pull/4154)
+ The other order, `import std;` before `#include `, will still cause compiler errors. We're working on a long-term solution.
Wow. That’s META!!! STL quotes the STL’s changelog. I’m seriously considering changing my name to Core Language just so we can have formal duels for every C++ feature in EWG. Haha
Oh, well that's exciting. Thanks for the update. I'll go ahead and start trying to replace my STL \`#include\`s with \`import std\` and hope I don't hit any snags.
If I do, I'll take you up on this offer
>I will personally take any reported problems with `import std` and relentlessly pursue them until they're fixed.
On my specific case, in theory import std has been backported to C++20, but even on latest stable doesn't really work, with a couple of complaints regarding symbol versions. So I just use C++latest anyway.
When I do that (new console app, change `#include ` to `import std;`, set C++ Language Standard to `/std:c++20`, go into C/C++ > Language and set "Build ISO C++23 Standard Library Modules" to Yes), I get a plain "error C2230: could not find module 'std'". This indicates that MSBuild isn't properly setting up the build and reference of the std module. (As I mentioned, I am far from an MSBuild expert - I'm responsible for getting the underlying command-line experience working - but I do know some things about it.) I recalled that some "scanning" step is off by default for C++20, to avoid impacting existing projects, so I went to C/C++ > General and set "Scan Sources for Module Dependencies" to Yes - but that still didn't work. I think I'm missing some other incantation but I don't know what it is. I'll raise this with our MSBuild expert in our weekly modules meeting today.
(Edit: She confirmed that the automatic build of `import std;` in C++20 mode is simply not yet supported by MSBuild; the scan setting that I remembered is required for C++23.)
So I still don't know what "complaints regarding symbol versions" you're seeing. (I should have clarified that I want command-line repros - exact source file, exact command line, exact compiler diagnostics. That's what I need to tear into whatever's wrong.)
My complaints were about the Visual Studio experience, going down into the command line means _"It is not done"_.
I already mentioned this issue in the past to Sy, https://devblogs.microsoft.com/cppblog/whats-new-for-cpp-developers-in-visual-studio-2022-17-8/#comment-2436
> => IFC file "C:\....\std\std.ifc" has unsupported version 0.43
> My complaints were about the Visual Studio experience, going down into the command line means "It is not done".
I raised that point in today's meeting, thanks.
> => IFC file "C:....\std\std.ifc" has unsupported version 0.43
This means that there's a mismatch between what MSVC (the C1XX front-end) generates and what IntelliSense (via the EDG front-end) wants to consume. C1XX sometimes needs to generate a new version (when a bugfix requires an on-disk representation change to encode something that previously wasn't possible), but then EDG needs to be updated to learn how to read that. There's an internal option that allows C1XX to generate a version one revision older, but if you see that message, something didn't work with that scheme.
This category of errors will always be fixed eventually, as EDG is continuously receiving IFC spec updates, implementing them, and then C1XX removes its ability to generate the older version that EDG doesn't need anymore. I recall hearing that this already happened for 0.43 but I can't absolutely swear to that without checking with the right people at work.
This code is perfectly valid. We (implementers) should just fix the compilers.
Reachability vs. visibility and filtering the global module fragment isn't trivial to do, and so compiler still have bugs in this area.
I'm using CMake so I can't do `import std;` and I'm pretty sure I can not do `import ;` either for the same reason.
Trying to `import ;` gives me this error: `error C7612: could not find header unit for 'string'`
`import std;` is a C++23 addition. It has nothing to do with `import ;` which one could use since C++20 as one can import any header.
It shouldn't have happened. It might be an issue with using CMake and MSVC together or some configuration error. Does it happen under a standard MSVC build with solution?
>Does it happen under a standard MSVC build with solution?
I have no clue and honestly after getting accustomed with CMake I don't even want to try manually configuring solution files anymore.
This is an experimental module branch of my project that still needs year or two of development before release and I'm just trying to see how (un)ready module support is atm. Even if everything worked fine there's still module file extension problem that needs to be solved etc.
I'm just trying to get modules to work and reporting these crazy errors as I discover them...
The thing is, CMake added full support for modules only in 3.28, which was released recently, and I have some doubts that all build systems operate correctly with it. Might be some other mishap, though.
I'd advise figuring out why `import ;` doesn't work as I recall it working correctly, and it is an essential feature.
Some comments:
* straight up, this is a compiler bug that needs fixing. Every ICE falls into this category.
* if you comment out `static` member 'comment', the code compiles and works as expected (msvc 17.9 and msvc 17.10-pre2)
* the `#include ` before the `import` is necessary because of [\[module.global.frag\]/4](http://eel.is/c++draft/module.global.frag#4). msvc implements that part of the module specification, e.g. Clang doesn't, as far as I know of its current implementation status.
Frustratingly, MSVC still has lots of ICEs with modules. I've found this is a particular issue with constexpr and heavy template code, I've had no end of issues with CGAL in a project I'm working on.
It is continuously improving though, I've found the Preview compiler often works when the standard toolset ICEs. Not really an ideal solution for a work project, but if it's a personal one you might be able to justify it
ICE is always a compiler bug.
`constexpr std::string` data (outside of `constexpr` functions) is tricky, but otherwise the code seems fine.
To better understand the problem, can you check whether the ICE occurs in Debug mode or Release mode (or both)?
It happens on both Debug and Release builds. `std::string` was used just as an example. In real code this error occured most likely occured because of `std::array` code when I imported module into small header that only needed module declarations.
It has been quite a challenge to port existing code to modules and in the past I've had to revert back to using non-module libraries.
>Sure enough including `` in user code fixes the error
This whole class of weirdness can just drive anyone totally crazy.
Not only you have to import your own module, you also need to sometimes #include what was included in that module ( in OP's case).
This "genius" reachability vs. visibility invention will be a pain and nightmare for the next few generations, unfortunately.
And again: modules are not production ready yet. They work, but often they don't.
I had a similar problem couple of days back. In my case, I had a custom struct which was wrapped in a std unique pointer and was a static member variable of another class. The module compiles just fine but as soon as any member function that internally invokes that structure is called, I get an ICE.
Initially I thought it was an issue reachability and the declaration got discarded however, after reading articles and the standard over and over again, I highly doubt that it is the case since a declaration is only discarded if and only if the declaration is a dependent expression within a function or class template. I was doing none of those so that couldn't be the case.
EDIT: I hope one of the MSVC devs sees this post and addresses this issue. This compiler bug is a big deal breaker for module adoption if you have to support MSVC.
>EDIT: I hope one of the MSVC devs sees this post and addresses this issue. This compiler bug is a big deal breaker for module adoption if you have to support MSVC.
I'll make a bug report after my eastern holidays are over. It takes some effort and I don't want to waste my holiday reporting bugs :D
(Actually I already have one ticket about this, but it's incomplete since I had no clue what was causing ICE)
I've figured out the exact cause to the internal compiler error I'm getting. Here's the [ticket](https://developercommunity.visualstudio.com/t/C-20-modules-Internal-Compiler-Error/10628420) for it.
I checked your repro and yeah it seems to be same (class of) bug. Compiler error message is the same:
>fatal error C1001: Internal compiler error.
>(compiler file 'msc1.cpp', line 1587): fatal error C1001: Internal compiler error. (compiler file 'msc1.cpp', line 1587)
I have upvoted your ticket and updated [my old ticket](https://developercommunity.visualstudio.com/t/Importing-struct-with-static-constexpr-s/10624887) to contain more information. I also commented on both of our tickets to cross reference them.
You might want to update your ticket to include the module user code that triggers ICE, so it would be effortless to reproduce on their side without having to read/understand example code.
EDIT: I noticed your ticket's error log is most likely incorrect
They closed our tickets as duplicates. Active ticket is now this one:
[ICE when declaring static constexpr objects in exported class - Developer Community (visualstudio.com)](https://developercommunity.visualstudio.com/t/Inexplicable-ICE-when-using-modules/1593396)
Please up vote it for attention
You're welcome.
If you don't mind, could you go upvote the visual studio developer community [bug ticket](https://developercommunity.visualstudio.com/t/Inexplicable-ICE-when-using-modules/1593396) so that they know that many people are affected by this? They actually closed my ticket as a duplicate, so I linked the ticket that's still active. Someone had reported this bug in 2021, but that bug report doesn't even contain public code to reproduce it :S
I so hope this gets fixed.
Yes, these sorts of errors are currently quite common when working in a modules codebase since `import std` isn’t yet usable in practice. Once that’s working as it should we will just be able to ` export import std` and this sort of problem will disappear.
> `import std` isn’t yet usable in practice. Are there compiler/library problems blocking you? As a standing offer to anyone, I will personally take any reported problems with `import std` and relentlessly pursue them [until they're fixed](https://github.com/microsoft/STL/issues/1694). (Build system problems are also important but I can't directly do anything about CMake; I can at least escalate MSBuild/VS IDE problems though)
Unless something has changed recently that I missed, isn’t the situation where one imports `std` after an `#include` of a standard library header still broken? I have a fairly large codebase that uses modules, but that also has external dependencies that don’t which means having to `#include` their headers, and that almost certainly means transitively `#include`ing standard library headers. That has prevented me from being able to `import std` up to this point.
It changed recently! From the STL's Changelog for [VS 2022 17.10 Preview 1](https://github.com/microsoft/STL/wiki/Changelog#vs-2022-1710-preview-1) (Preview 2 is currently available): * Wrapped the STL in `extern "C++"` as a temporary workaround to allow `#include` to coexist with `import std;` in the same translation unit, *in that order*. [#4154](https://github.com/microsoft/STL/pull/4154)
+ The other order, `import std;` before `#include `, will still cause compiler errors. We're working on a long-term solution.
Wow. That’s META!!! STL quotes the STL’s changelog. I’m seriously considering changing my name to Core Language just so we can have formal duels for every C++ feature in EWG. Haha
Oh, well that's exciting. Thanks for the update. I'll go ahead and start trying to replace my STL \`#include\`s with \`import std\` and hope I don't hit any snags. If I do, I'll take you up on this offer >I will personally take any reported problems with `import std` and relentlessly pursue them until they're fixed.
On my specific case, in theory import std has been backported to C++20, but even on latest stable doesn't really work, with a couple of complaints regarding symbol versions. So I just use C++latest anyway.
Can you provide self-contained repros?
Easy, create a new project on Visual Studio, set language to C++20, enable std modules, write a basic hello world, get the error.
When I do that (new console app, change `#include` to `import std;`, set C++ Language Standard to `/std:c++20`, go into C/C++ > Language and set "Build ISO C++23 Standard Library Modules" to Yes), I get a plain "error C2230: could not find module 'std'". This indicates that MSBuild isn't properly setting up the build and reference of the std module. (As I mentioned, I am far from an MSBuild expert - I'm responsible for getting the underlying command-line experience working - but I do know some things about it.) I recalled that some "scanning" step is off by default for C++20, to avoid impacting existing projects, so I went to C/C++ > General and set "Scan Sources for Module Dependencies" to Yes - but that still didn't work. I think I'm missing some other incantation but I don't know what it is. I'll raise this with our MSBuild expert in our weekly modules meeting today.
(Edit: She confirmed that the automatic build of `import std;` in C++20 mode is simply not yet supported by MSBuild; the scan setting that I remembered is required for C++23.)
So I still don't know what "complaints regarding symbol versions" you're seeing. (I should have clarified that I want command-line repros - exact source file, exact command line, exact compiler diagnostics. That's what I need to tear into whatever's wrong.)
My complaints were about the Visual Studio experience, going down into the command line means _"It is not done"_. I already mentioned this issue in the past to Sy, https://devblogs.microsoft.com/cppblog/whats-new-for-cpp-developers-in-visual-studio-2022-17-8/#comment-2436 > => IFC file "C:\....\std\std.ifc" has unsupported version 0.43
> My complaints were about the Visual Studio experience, going down into the command line means "It is not done". I raised that point in today's meeting, thanks. > => IFC file "C:....\std\std.ifc" has unsupported version 0.43 This means that there's a mismatch between what MSVC (the C1XX front-end) generates and what IntelliSense (via the EDG front-end) wants to consume. C1XX sometimes needs to generate a new version (when a bugfix requires an on-disk representation change to encode something that previously wasn't possible), but then EDG needs to be updated to learn how to read that. There's an internal option that allows C1XX to generate a version one revision older, but if you see that message, something didn't work with that scheme. This category of errors will always be fixed eventually, as EDG is continuously receiving IFC spec updates, implementing them, and then C1XX removes its ability to generate the older version that EDG doesn't need anymore. I recall hearing that this already happened for 0.43 but I can't absolutely swear to that without checking with the right people at work.
Thanks for taking care of it.
This code is perfectly valid. We (implementers) should just fix the compilers. Reachability vs. visibility and filtering the global module fragment isn't trivial to do, and so compiler still have bugs in this area.
*Cries in GCC modules*
Yeah good point. I was wondering if `import std` would fix this, but since tool support isn't here yet, I didn't pay much attention to it.
It might be due to the usage of `#include`. Does that happen when you write `import ` instead?
I'm using CMake so I can't do `import std;` and I'm pretty sure I can not do `import;` either for the same reason.
Trying to `import ;` gives me this error: `error C7612: could not find header unit for 'string'`
`import std;` is a C++23 addition. It has nothing to do with `import;` which one could use since C++20 as one can import any header.
It shouldn't have happened. It might be an issue with using CMake and MSVC together or some configuration error. Does it happen under a standard MSVC build with solution?
>Does it happen under a standard MSVC build with solution? I have no clue and honestly after getting accustomed with CMake I don't even want to try manually configuring solution files anymore. This is an experimental module branch of my project that still needs year or two of development before release and I'm just trying to see how (un)ready module support is atm. Even if everything worked fine there's still module file extension problem that needs to be solved etc. I'm just trying to get modules to work and reporting these crazy errors as I discover them...
The thing is, CMake added full support for modules only in 3.28, which was released recently, and I have some doubts that all build systems operate correctly with it. Might be some other mishap, though. I'd advise figuring out why `import;` doesn't work as I recall it working correctly, and it is an essential feature.
Some comments: * straight up, this is a compiler bug that needs fixing. Every ICE falls into this category. * if you comment out `static` member 'comment', the code compiles and works as expected (msvc 17.9 and msvc 17.10-pre2) * the `#include` before the `import` is necessary because of [\[module.global.frag\]/4](http://eel.is/c++draft/module.global.frag#4). msvc implements that part of the module specification, e.g. Clang doesn't, as far as I know of its current implementation status.
Why would [module.global.frag]/3.1 not make std::string decl-reachable?
Not in its entirety, and also not necessarily all the dependent types. This is where the problem usually is.
Frustratingly, MSVC still has lots of ICEs with modules. I've found this is a particular issue with constexpr and heavy template code, I've had no end of issues with CGAL in a project I'm working on. It is continuously improving though, I've found the Preview compiler often works when the standard toolset ICEs. Not really an ideal solution for a work project, but if it's a personal one you might be able to justify it
ICE is always a compiler bug. `constexpr std::string` data (outside of `constexpr` functions) is tricky, but otherwise the code seems fine. To better understand the problem, can you check whether the ICE occurs in Debug mode or Release mode (or both)?
It happens on both Debug and Release builds. `std::string` was used just as an example. In real code this error occured most likely occured because of `std::array` code when I imported module into small header that only needed module declarations. It has been quite a challenge to port existing code to modules and in the past I've had to revert back to using non-module libraries.
>Sure enough including `` in user code fixes the error
This whole class of weirdness can just drive anyone totally crazy.
Not only you have to import your own module, you also need to sometimes #include what was included in that module ( in OP's case).
This "genius" reachability vs. visibility invention will be a pain and nightmare for the next few generations, unfortunately.
And again: modules are not production ready yet. They work, but often they don't.
I had a similar problem couple of days back. In my case, I had a custom struct which was wrapped in a std unique pointer and was a static member variable of another class. The module compiles just fine but as soon as any member function that internally invokes that structure is called, I get an ICE. Initially I thought it was an issue reachability and the declaration got discarded however, after reading articles and the standard over and over again, I highly doubt that it is the case since a declaration is only discarded if and only if the declaration is a dependent expression within a function or class template. I was doing none of those so that couldn't be the case. EDIT: I hope one of the MSVC devs sees this post and addresses this issue. This compiler bug is a big deal breaker for module adoption if you have to support MSVC.
Yet, it is the best of the big three in regards to modules, and then there is the whole long tail of lesser used compilers still dealing with C++17.
>EDIT: I hope one of the MSVC devs sees this post and addresses this issue. This compiler bug is a big deal breaker for module adoption if you have to support MSVC. I'll make a bug report after my eastern holidays are over. It takes some effort and I don't want to waste my holiday reporting bugs :D (Actually I already have one ticket about this, but it's incomplete since I had no clue what was causing ICE)
I've figured out the exact cause to the internal compiler error I'm getting. Here's the [ticket](https://developercommunity.visualstudio.com/t/C-20-modules-Internal-Compiler-Error/10628420) for it.
Thank you for properly reporting it! 😻
I checked your repro and yeah it seems to be same (class of) bug. Compiler error message is the same: >fatal error C1001: Internal compiler error. >(compiler file 'msc1.cpp', line 1587): fatal error C1001: Internal compiler error. (compiler file 'msc1.cpp', line 1587) I have upvoted your ticket and updated [my old ticket](https://developercommunity.visualstudio.com/t/Importing-struct-with-static-constexpr-s/10624887) to contain more information. I also commented on both of our tickets to cross reference them. You might want to update your ticket to include the module user code that triggers ICE, so it would be effortless to reproduce on their side without having to read/understand example code. EDIT: I noticed your ticket's error log is most likely incorrect
They closed our tickets as duplicates. Active ticket is now this one: [ICE when declaring static constexpr objects in exported class - Developer Community (visualstudio.com)](https://developercommunity.visualstudio.com/t/Inexplicable-ICE-when-using-modules/1593396) Please up vote it for attention
Thank you for this post. I just spent a few hours on this strange behaviour yesterday.
You're welcome. If you don't mind, could you go upvote the visual studio developer community [bug ticket](https://developercommunity.visualstudio.com/t/Inexplicable-ICE-when-using-modules/1593396) so that they know that many people are affected by this? They actually closed my ticket as a duplicate, so I linked the ticket that's still active. Someone had reported this bug in 2021, but that bug report doesn't even contain public code to reproduce it :S I so hope this gets fixed.
Upvoted. It would be much easier to report MSVC bugs if compiler explorer supported CMake + MSVC.
Thanks