Reputation: 7925
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:
disabling
the Visual Studio
compiler feature?The Khronos Group
or LunarG
who are responsible for the Vulkan
library, Microsoft
as they are adding this feature to their compiler
or would this be something that would concern the actual C++ Standard
? module
going to be considered an actual key word
within the C++
language from the standard or will this be a Microsoft specific thing?gcc
or Clang
effected by this?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
Reputation: 48216
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.
You can edit the vulkan header, the name of the member field doesn't matter for correct operation.
Microsoft needs to fix their compiler.
It is going to be a contextual keyword.
If they implement the contextual keyword correctly then they will not be affected.
Upvotes: 4