adds experimental support for C++20 modules #248

cjdb · 2025-05-23T22:56:59Z

Programmers can now use import cpptrace; instead of needing to include headers. Support is currently experimental.

Since macros aren't exported by modules, users need to include either <cpptrace/exceptions_macros.hpp> or <from_current_macros.hpp>, depending on their needs.

cjdb · 2025-05-23T23:09:57Z

Blocked by #249.

Programmers can now use `import cpptrace;` instead of needing to include headers. Support is currently experimental. Since macros aren't exported by modules, users need to include either `<cpptrace/exceptions_macros.hpp>` or `<from_current_macros.hpp>`, depending on their needs.

jeremy-rifkin

Thanks so much for taking the time to do this. I think everything looks good to me, a couple quick comments

jeremy-rifkin · 2025-05-25T22:22:41Z

cmake/InstallRules.cmake

@@ -25,6 +25,7 @@ install(
  ARCHIVE #
  COMPONENT ${package_name}_development
  INCLUDES #
+  FILE_SET CXX_MODULES


I'm not familiar with this option but I'll trust this does something reasonable :)

This installs the module interface unit :)

jeremy-rifkin · 2025-05-25T22:28:58Z

cmake/Autoconfig.cmake

+  # check_cxx_source_compiles doesn't support modules (yet?) so we need to drop
+  # to a raw try_compile.
+  try_compile(
+    HAS_CXX20_MODULES


It looks like this test will pass for much older versions of clang than I was expecting, all the way back to clang 10 while I'm under the impression the module implementation only got more feature-complete and stable recently https://gcc.godbolt.org/z/4r73zGxd6. On the other hand, it won't work for any version of gcc because of -fmodules (which might be ok, not sure how stable gcc is yet but I'm under the impression they're at least close to feature-complete / stability). Thoughts on how best to approach this? I'm not sure what the best default behavior is.

Hmm, that's going too far back. CMake support for modules is only very recent, so I guess we could gate on compiler versions?

I'm thinking compiler version might be more robust yeah (but more of a hassle to check)

jeremy-rifkin · 2025-05-25T22:29:49Z

src/cpptrace_module.cpp

+
+export module cpptrace;
+
+namespace cpptrace::inline v1 {


Is it possible to rely on the begin/end namespace macros here?

Yep, I'll get on that.

jeremy-rifkin · 2025-05-25T22:40:03Z

include/cpptrace/from_current_macros.hpp

@@ -0,0 +1,54 @@
+#ifndef CPPTRACE_FROM_CURRENT_MACROS_HPP


Out of curiosity, is there a sensible way to make either of the following work instead of a new macros header?

#include <cpptrace/from_current.hpp> import cpptrace; // or import cpptrace; #include <cpptrace/from_current.hpp>

If a macros header is the best way to do this I think it's good with me - and I'm guessing if so other libraries might follow the same pattern. But I'd love to be able to keep #include <cpptrace/from_current.hpp> under modules if possible as that is currently in a sense part of the library interface.

We can do the former, but not the latter (yet). Having said that, including cpptrace/from_current.hpp will undo some or all of the hard work that modules is accomplishing. I'm not aware of a better way to import macros from a module library than to do

#include <cpptrace/from_current_macros.hpp> import cpptrace;

Once support for modules stabilises, I'd recommend the docs encourage header users not include the _macros.hpp headers, and instead just stick with the original headers (which export the macros).

…terface, it's special

ChuanqiXu9 · 2025-05-26T05:01:04Z

src/cpptrace_module.cpp

@@ -0,0 +1,102 @@
+module;


I suggest module interface files to end with .cppm instead of .cpp. It improves the readability slightly.

I'm not convinced that .cppm improves the readability. Could you elaborate, please?

The uniform convention can help people to identify things more easily. E.g., I can search for *.cppm in github to find the repos supporting modules. Or we can count the number of module interfaces more easily.

Unfortunately, as is the way of C++, it looks like people are already using a wide variety of extensions for modules https://github.com/search?type=code&q=%2F%5E%28%3F-i%29module%3B%2F+language%3Ac%2B%2B+-is%3Afork&p=1. I'm not super opinionated on this issue.

Yeah, this is not a forcement but a suggestion.

The reason I'm avoidant is because the original GCC modules implementer told me that he was discouraging a different file extension after some experience. I don't think LLVM has that same aversion.

Having said that, I've literally named the file cpptrace_module.cpp to disambiguate it from cpptrace.cpp. I think cpptrace.cppm might be the better of the two, even if I'd rather stick with just .cpp.

After discussion I went ahead and updated it to .cppm - since this file will be installed to share/ I think it's good to make it clear it's a module file and not just some random .cpp file.

wreien · 2025-05-26T07:47:40Z

cmake/has_modules.cpp

@@ -0,0 +1,4 @@
+export module cpptrace;
+
+int main()


Note main is not by current standard allowed to be attached to a named module and at least GCC15 will diagnose this.

I was surprised this worked at all. The correct thing to do was to add -fsyntax-only to the try_compile job, but I think this file is redundant now anyway.

jeremy-rifkin

LGTM, thanks so much for putting this together!

cjdb force-pushed the modules branch from d065b04 to 967964c Compare May 24, 2025 00:49

jeremy-rifkin reviewed May 25, 2025

View reviewed changes

jeremy-rifkin added 7 commits May 25, 2025 17:47

Try to fix integration test

ded6ca9

Try to fix CI

1a0454c

Detect module support with compiler versions

c73cceb

Remove register_jit_objects_from_gdb_jit_interface from the module in…

6c27579

…terface, it's special

Misc

d3d6bdc

Remove gdb_jit include

25a75dc

Fix for bazel

2375e9f

ChuanqiXu9 reviewed May 26, 2025

View reviewed changes

jeremy-rifkin added 3 commits May 26, 2025 00:06

Fix for bazel

af8b2db

Fix install rules

190a07e

Set a destination for the modules file set

a6f5018

wreien reviewed May 26, 2025

View reviewed changes

jeremy-rifkin added 2 commits May 26, 2025 11:47

Update modules install destination

0a8c500

Cleanup and rename module to .cppm

ec9f31c

jeremy-rifkin approved these changes May 26, 2025

View reviewed changes

jeremy-rifkin merged commit 2b6cf03 into jeremy-rifkin:dev May 26, 2025
99 checks passed

adds experimental support for C++20 modules #248

adds experimental support for C++20 modules #248

Uh oh!

Conversation

cjdb commented May 23, 2025

Uh oh!

cjdb commented May 23, 2025

Uh oh!

jeremy-rifkin left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jeremy-rifkin May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jeremy-rifkin left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jeremy-rifkin May 26, 2025 •

edited

Loading