Add C++20 modules support and format btw.

[Perdixky]

As the library depends on C++20, I think the support for modules is definitely important 😊
So I’ve added this.
If this change is approved, I’ll add the corresponding documentation later.
By the way, should we convert all the test files to use modules? This would prevent errors caused by missing exported entities, but it might be a bit aggressive.

[gemini-code-assist]

Code Review

This pull request introduces experimental support for C++20 modules, adding module interface files and updating the CMake build system to support module compilation and installation. It also refactors internal headers to use inline and constexpr for improved linkage. Feedback highlights that changes to the third-party yyjson.h header break C compatibility by using C++-specific keywords; these macros should be guarded with preprocessor checks to maintain support for C users.

[liuzicheng1987]

Hi @Perdixky , thanks for your contribution. To be honest, we have tried adding module support a while ago and back then there were so many problems that we decided modules are not yet ready for prime time. But I'd be happy to give them another try.

[liuzicheng1987]

@Perdixky , could you also add the module tests that you have written to the automated Github Actions testing pipeline? It does not appear that your tests are actually compiled or executed.

[liuzicheng1987]

@Perdixky, are you planning to continue working on this? Otherwise I will have to close this due to inactivity?

[Perdixky]

@Perdixky, are you planning to continue working on this? Otherwise I will have to close this due to inactivity?

@liuzicheng1987 , I'm a bit busy at this moment, but I'll follow up on this work! Please bear with me for a few weeks!

[liuzicheng1987]

@Perdixky no problem!

[Perdixky]

Hi @liuzicheng1987! There are a few issues I need to report:

• Some binary module interfaces (BMIs) are affected by macros like REFLECTCPP_ENUM_RANGE_MIN. Therefore, we need to add some CMake options and use the -D argument to control the behavior.
• It's not ideal to export all objects from headers, so we need to use the following structure:

module;
#include"rfl/cli.hpp"exportmodule rfl.cli;
exportimport rfl;
exportnamespacerfl::cli {
using ::rfl::cli::read;
}

• I'm going to refactor all tests to import modules, because this can force contributors to add/remove APIs in the .cppm files.
• Some small bugs were discovered during the migration, such as:

namespacestd {
template <int I, class... Types>
constexprauto& get(rfl::Tuple<Types...>&);
}

which is undefined behavior and cannot be exported by modules. I'll make a manifest later so that you can decide how to handle them.

[liuzicheng1987]

@Perdixky you should merge main into your feature branch. Some of these issues might already be resolved.

[Perdixky]

@liuzicheng1987 These commits have already been shipped. Please feel free to review them and let me know if you have any feedback!

[liuzicheng1987]

@Perdixky there seem to be significant issues. Could you take another look?