Francis Cugler
Francis Cugler

Reputation: 7925

Visual Studio's /experimental:module conflicting with Vulkan's core.h causing syntax error - compilation failure

A little forward message: since I was limited to the number of tags I was able to use, I chose the tag visual-studio although this pertains to at least Visual Studio 2015 minimum which is less of a concern as this is focused more towards the use of Visual Studio 2017 or Visual Studio 2019 with the language version being set to either C++17 or C++20.


I have noticed a peculiar conflict between these versions of Visual Studio and Vulkan v1.1

If one is building a Vulkan based application and they happen to turn on the compiler flags: /std:c++latest and /experimental:module

Documentation found from here:

and tries to compile and or link against the Vulkan library it fails due to a the aforementioned conflict.


There is a major failure that is coming from vulkan_core.h as some of their defined structures have a member that is named module which can be seen from their spec sheet: khronos/vulkan/specs/1.1-extensions...

In Vulkan's VkPipelineShaderStageCreateInfo structure they have it defined like this:

typedef struct VkPipelineShaderStageCreateInfo {
    VkStructureType                     sType;
    const void*                         pNext;
    VkPipelineShaderStageCreateFlags    flags;
    VkShaderStageFlagBits               stage;
    VkShaderModule                      module;
    const char*                         pName;
    const VkSpecializationInfo*         pSpecializationInfo;
} VkPipelineShaderStageCreateInfo;

which contains a VkShaderModule named module and this conflicts with Visual Studio's /experimental:module compiler flag since this enables module to become a keyword within the C++17 and or C++20 languages.

This feature is available in Visual Studio 2017 and Visual Studio 2019, I'm not 100% sure but I think it is also available in Visual Studio 2015 as I think this is when Microsoft introduced it.


There has been a brief topic, thread or discussion about this found here: https://developercommunity.visualstudio.com/content/problem/556929/enabling-modules-causes-syntax-error-in-vulkan-cor.html They mention that it is being investigated but I don't see much more on this topic than what I've found.

I even tried to search here first to see if there was any mention of it, but my search results were fruitless. So I decided to post this question as more of an awareness and reference to other users as I think that this is an important issue to address since Vulkan is becoming a popular 3D Graphics and Compute API tool to use.


So to my question(s) regarding this issue:


I had asked these series of questions to get an overall feedback from the community as a whole.

I would also like to see others contribute to this post adding links of other discussions, plans, and possible resolutions that pertain and or are related to this specific topic making this a reference page for all readers of the C++ community!

Upvotes: 2

Views: 385

Answers (1)

ratchet freak
ratchet freak

Reputation: 48216

  • Are there any followups other than what was mentioned?

The public issue tracker of vulkan has a topic on it: https://github.com/KhronosGroup/Vulkan-Docs/issues/568

The resolution is that module is to become a contextual keyword so the compiler shouldn't give an error on it.

  • Is there any work around other than disabling the Visual Studio compiler feature?

You can edit the vulkan header, the name of the member field doesn't matter for correct operation.

  • Where would the responsibility of taking care of this fall to.

Microsoft needs to fix their compiler.

  • Also; is module going to be considered an actual key word within the C++ language from the standard or will this be a Microsoft specific thing?

It is going to be a contextual keyword.

  • Are other compilers such as gcc or Clang effected by this?

If they implement the contextual keyword correctly then they will not be affected.

Upvotes: 4

Related Questions