Feature/module

[ClausKlein]

e049443 Feat: Modernize CMakeLists.txt to build and install CXX_MODULE asio the Daniela's way

• Use import std; where toolchain supports it
• Change Windows CI Workflow to use import std; too
• CI workflow with gcc-15, gcc-16
• CI workflow with clang-21, clang-22
• CI workflow with MSVC 2025
• Add more examples
• Add tests?

[DanielaE]

Great! 🎉
I will check later this day if the additional change sets on top of mine still work here.

[ecoezen]

hey! import std in asio.ixx must be moved after asio module declaration, but remaining comments are not critical that requires changes, an left for general discussion, and potential quality improvements.

[anarthal]

Does

import std;
import asio;

work under any of the compilers? without ifdef-ing includes out, I got the impression it probably doesn't as of today. Are you running the test suite importing instead of including?

[DanielaE]

At least it did in 2022 (see my plenary talk at CppCon 2022 and some of my later talks), and it still does today.

I've tested with msvc and clang back then, but not with gcc (for obvious reasons).

[DanielaE]

I've done a quick check with VS2026, building Asio with the additional changeset both as a named module and a header unit. The build of a small in-house application of ours together with the modularized standard library and a couple of other modules is fine, and the application works a expected.

[ClausKlein]

Does

import std;
import asio;

work under any of the compilers?

yes, not all compilers(Not appleclang), but with MSVC, clang-19+, gcc-15+ it works

Only the current Windows CI has to be modernised
It has only Cmake v3.31.6, for import std we need v4.2+

without ifdef-ing includes out, I got the impression it probably doesn't as of today. Are you running the test suite importing instead of including?

NOT yet, I need to write CMakeLists.txt for the tests, I dit is years ago, It should be possible again.

[anarthal]

I've done a little playing and this fails to compile under clang-22/libc++/Ubuntu 24.04:

import std;
import asio;
#include <iterator>

Interestingly, this builds fine:

import asio;
#include <iterator>

I recalled that the problems with mixing include and import std happened transitively, but it looks like this is not the case anymore.

[anarthal]

FYI, in my Boost modularization prototype I'm using the notion of "compatibility headers", which will include the standard header or not depending on a config macro (like your ASIO_HAS_IMPORT_STD). This way you don't need to add so many ifdefs, you only need to replace the include:

https://github.com/anarthal/config/blob/feature/cxx20-modules/include/boost/config/std/algorithm.hpp

[ecoezen]

FYI, in my Boost modularization prototype I'm using the notion of "compatibility headers", which will include the standard header or not depending on a config macro (like your ASIO_HAS_IMPORT_STD). This way you don't need to add so many ifdefs, you only need to replace the include:

https://github.com/anarthal/config/blob/feature/cxx20-modules/include/boost/config/std/algorithm.hpp

yes, actually i personally adopted compat headers way as well. it is far more cleaner than preprocessor clutter. i am working on it now.

[ecoezen]

i'll look at CI stuff soon. fyi @ClausKlein

mostly resolved by last commits

[ClausKlein]

@ecoezen we should add a Windows CI build on windows-2025-vs2026 too!

[ecoezen]

hey @ClausKlein. I clean up cmake a bit, introduce an initial cmake presets configuration and updated actions accordingly. i noticed we werent tested import std properly in previous workflows. current failures are import std failures with both clang and gcc. msvc works fine on both modes. feel free to tweak workflows, run conditions etc as i may have changed your initial configurations.

notes/todos:

• hard coded public flags on targets were problematic as modules are extremely sensitive for flag differences (e.g. not setting /EHsc for import std, but using it on asio module). moved all into the preset. we can create individual toolchain files, if desired.
• mingw disabled for now to save ci time. we should first resolve problems with clang and gcc on linux imo.
• we should also bring vs2026, but i believe it will just work flawlessly (which it is locally for me) so we should focus on import std on linux.

current failure:

• clang with import std: clang++ reports wrong path for libc++.modules.json and cmake not helpful even when setting CMAKE_CXX_STDLIB_MODULES_JSON manually. i'm looking at it. i think i saw your bug report on cmake, which is the reason for the failure.

• gcc with import std: seems we need some workarounds for macro provided std headers. i think we can reduce some of them by adding complaining macro providing std headers to 'MACRO_STD_HEADERS' in module_compat.cmake and regenerate headers. currently investigating.

=> last 2 commits are still WIP in nature. if you don't like the direction, please feel free to revert it and direct me accordingly. @ClausKlein

[anarthal]

Note that for gcc, include and then import works for std, but the other way around doesn't. This applies even if the included file is located in a TU that becomes reachable through an import.

[ecoezen]

Note that for gcc, include and then import works for std, but the other way around doesn't. This applies even if the included file is located in a TU that becomes reachable through an import.

by the commit b12e96c, there is no longer any std includes in module purview. all std includes strictly restricted in global module fragment, with the help of compability headers that guard std header inclusions with ASIO_IN_GMF preprocessor definition. thus, the aforementioned error has been already resolved for the standard library usage in asio. fyi.

logic is as following:

1. import std supported: only some macro providing std headers included in gmf, rest is provided by import std. no purview inclusion of std headers.
2. no import std: all std headers included in gmf. no purview inclusions of std headers.

[ecoezen]

hey @ClausKlein, I pushed a few updates to the PR. when you have a chance, could you take a look and let me know what you think? happy to iterate further if needed.

[DanielaE]

You understand that enclosing a declaration with an extern "C++" linkage specification [dcl.link] doesn't affect the linkage of inline variable 'winsock_init_instance' at all, right? It has module linkage, "C++" language linkage like before. The only change is in attachment.

That variable will get initialized as soon as module 'asio' is nominated for import for the first time in transitive appearance order of the module interface dependency tree.

[ecoezen]

you are right, my wording was poor. the intent is indeed to detach the declaration from the named module so it is no longer attached to asio. i still sometimes (incorrectly) use terms like external/global linkage when i really mean module attachment tweaks, so thanks for the correction.

with msvc 19.50 we observed that an unexported inline definition attached to the module can be discarded if it is not referenced within the module unit itself. when consumers import asio and instantiate templates that reference winsock_init_instance, the linker then fails to find the definition.

placing it inside a linkage-specification detaches the declaration, which makes msvc emit the definition normally and resolves the linker errors. i also considered __declspec(selectany) as an alternative, but this approach seemed preferable since it avoids compiler-specific attributes.

[DanielaE]

I don't see that in my own current tests using cl.exe 19.50.35725, but did some time in the past:

Miscompiled dynamic initializers

Anyway, do whatever you prefer, it doesn't really matter.

[ecoezen]

interesting. you can observe the related failure at 4d3168d CI

i have the same error with msvc 19.50 on a different project.

[DanielaE]

This is a different problem: you see a missing linker symbol. I never did.

The problem that I've reported back to the compiler team was the fact that the code for initializing the variable (i.e. the call to the initializer) wasn't even generated in the first place. 💥at the first instance where an initialized WinSock is required. This is what I am testing for.

[ecoezen]

yes! that's why i got a bit confused because the error i was facing was a simple codegen bug that boom during linking. i hope this fix survives your initialization tests without any 💥!