Add C++20 module interface file and tests

[sharadhr]

Resolves #1580.

VulkanHppGenerator and CMakeLists.txt have been modified to produce a C++20 vulkan.cppm module file that exports all types, structs, functions, names, handles, etc. used by Vulkan in the module, vulkan. C++20 users can now consume all of Vulkan-Hpp with a single line: import vulkan;.

Additional new features include consteval auto functions for macros that take numeric parameters, and constexpr auto variables for macros, both prefaced with c. So, VK_MAKE_API_VERSION is now vk::makeApiVersion, and is consteval-callable. A notable exclusion is VK_DEFINE_HANDLE, which performs macro magic, and cannot really be consteval-ed, trivially.

---

This is still a draft, as MSVC emits errors and warnings pertaining to vk::getDispatchLoaderStatic() being declared but not defined, and vk::anonymous-namespace::throwResultException() being, well, in an anonymous namespace. Resolved with 32d5a69 and c416dc2.

This is an RFC and I'm looking for feedback on my code. There are still a few things to be done, besides correcting the above-mentioned warnings and errors:

• Copy and convert all of the existing suite of samples and tests to using vulkan;;
• As mentioned in the TODO, some of the free functions in vulkan_funcs.hpp were eye-balled and hard-coded into the generator. It is very difficult to follow the recursive generateCommand... functions, and I'm hoping the maintainers have some input for this... Resolved with 7b4969b.
• Somehow verify that all types currently available in vulkan.hpp and vulkan_raii.hpp indeed were exported, and they are correctly guarded by macros;
• Export types from vulkan_format_traits.hpp, vulkan_extension_inspection.hpp and vulkan_hash.hpp. Resolved with 09a1177.

Thanks, and all feedback is welcome.

[CLAassistant]

All committers have signed the CLA.

[sharadhr]

With respect to c416dc2, the tests that make reference to it, specifically ArrayProxy.cpp, DesignatedInitializers.cpp, and StridedArrayProxy.cpp do not build successfully, even on the main branch.

I am using MSVC 19.35, Visual Studio 2022, CMake 3.26, Ninja 1.11.0. Not sure if they are broken tests or I'm doing something wrong.

[sharadhr]

I was also thinking if we should add signpost comments to vulkan.ixx similar to the other header files, such as:

//===============
//=== STRUCTS ===
//===============

so that users know where each type is defined. Of course, IDEs come with a go-to-definition/declaration feature, but maybe this is useful. Any thoughts?

[Agrael1]

Experimenting with exporting vulkan module I came to a point, where compiler started to complain about std::weak_ordering and other structs, I had to resort to VULKAN_HPP_NO_SPACESHIP_OPERATOR definition. Is that solved somehow?

[sharadhr]

@Agrael1, I have written a simple test, where I simply re-defined the vk::ApplicationInfo struct as applicationInfo2 in
tests/Cpp20Modules/Cpp20Modules.cpp, explicitly called operator<=>, with control flow depending on the result.

While Visual Studio's IntelliSense doesn't detect the VULKAN_HPP_HAS_SPACESHIP_OPERATOR macro for code highlighting, MSVC cl.exe 19.35 compiles the code just fine, and runs fine, too; the debugger correctly jumps into the correct operator<=>() defined for vk::ApplicationInfo and returns the correct value.

Cpp20Modules.zip

[asuessenbach]

Wow, what a big PR!
And an important one as well. I'm pretty sure, having vulkan.hpp as a module will be very much appreciated by everyone who suffers from the long compile times when including it.
So, thanks a lot for your contribution here!
Besides all my comments below: maybe you could switch to a different clang-format version, to prevent all the formatting differences in vulkan.hpp and vulkan_raii.hpp. I think, 14.x is a good choice.

[sharadhr]

Okay; at this juncture, I think the PR is ready for complete review; I will move it from draft mode. Everything in the bag is included in vulkan.cppm and I have tried to be as detailed as possible in my commit messages. I have also added documentation about how to use vulkan.cppm.

When this is merged, I will post in CMake's forum about this, and hopefully the FindVulkan module is updated in the near future to add in the Vulkan-Hpp C++ module (why does everyone choose 'module' for totally different functionality?).

As for the CI, I have used some C++20 functionality (ranges and std::views range adaptors), so I think the CI pipelines should be updated.

I look forward to hearing what you guys have to say.

[asuessenbach]

For all those simple " using VULKAN_HPP_NAMESPACE::${name}" replacements, it's probably easier to just use that text and concatenate the name instead of calling replaceWithMap.

[asuessenbach]

clang++-12 on Ubuntu seems to have issues with ranges... any idea what that is and how to resolve that?

[sharadhr]

clang++-12 on Ubuntu seems to have issues with ranges... any idea what that is and how to resolve that?

I think clang++12 is a bit too old for ranges, but I'm not sure. The library certainly appears to be recent enough, it's libstdc++ 12...

[asuessenbach]

Please don't const_cast.
If you think the logic is too complex to be repeated, once for the constants and functions and once for the usings, you could introduce some preparing non-const function called in the VulkanHppGenerator constructor.

[sharadhr]

Okay; looks like the way I have implemented the macro functions needs to change if we are to make them work for C++11. I need to remove the auto return type (change to uint32_t?) and get rid of the enable_if_t and is_integral_v, which were only added in C++14 and C++17 respectively.

I was thinking about requiring std::is_unsigned instead of std::is_integral because it makes no real sense for a version number to have a negative sign... Any thoughts? This will require that the generator change further still.

[asuessenbach]

I think, staying with std::is_integral would be the best fit. Just don't use is_integral_v, but is_integral<T>::value.
And you don't need to append 'u' in the calls, then.

[asuessenbach]

Your PR looks great now and passes all CI steps!
That is, if you say you're done, I'd be happy to merge it.

[sharadhr]

I think I have nothing left to add! Thanks for assisting me with all the reviews; I think it is also ready to merge.

[asuessenbach]

It was a pleasure to review your PR.
Having C++20 modules with Vulkan-Hpp is a great step into the future!
So, thanks a lot for your contribution.