khronosgroup/vulkan-headers

Vulkan header files and API registry

Vulkan-Headers

Vulkan header files and API registry

This repository contains Vulkan header files, include files for C and C++, and related scripts and tests.

Most of the files in this repository are sourced from, or generated from, other repositories as described in CONTRIBUTING.md. Vulkan-Headers exists as a staging area for these files, most of which are then consumed by downstream repositories used to build SDK components such as the Vulkan Validation Layers and Conformance Test Suite.

Developers normally obtain headers from the official Vulkan-SDK. They can also use headers from, or packaged from, this repository.

In most cases, developers should only need the headers, not the scripts and other material in this repository. If you need to run the scripts, please use them from their canonical source in the Vulkan Specification repository.

Contributing

See the CONTRIBUTING.md

Building

See BUILD.md

SDK Support

Vulkan-Headers are shipped as part of the official Vulkan-SDK

C/C++ Package Manager Support

Vulkan-Headers are also supported by both conan & vcpkg.

Version Tagging Scheme

Updates to this repository which correspond to a new Vulkan specification release are tagged using the following format: v<version> (e.g., v1.3.266).

Note: Marked version releases have undergone thorough testing but do not imply the same quality level as SDK tags. SDK tags follow the vulkan-sdk-<version>.<patch> format (e.g., vulkan-sdk-1.3.266.0).

This scheme was adopted following the 1.3.266 Vulkan specification release.

vulkan-headers's Issues

WSI platform support needed for GGP (Stadia)

Google Games Platform (GGP) is the platform for Stadia.

WSI support needs to be added to Vulkan-Headers/vk_icd.h, and to Vulkan-Loader.

Adding @lenny-lunarg for non-API headers

Meaning of "bitvalues" in bitmasks?

Hey! 😄

I'm parsing vk.xml to do Jai bindings in https://github.com/osor-io/Vulkan. Trying to update to 1.2.170 I found a difference when parsing the bitflags that then reference the enums with the flag bits.

In line 272 and 273 there's VkAccessFlags2KHR and VkPipelineStageFlags2KHR which instead of using the attribute requires to reference the FlagBits enum they use bitvalues.

This seems to apparently mean the same in this case, but I wonder if I'm missing some key difference here (besides the fact that they are now 64 bits, which doesn't seem like it should be related).

Am I safe to handle bitvalues the same way as requires here? If that is a yes, why does it exist?

Upcoming renaming of master -> main branch (update: will occur 2021-08-31)

@mark-lunarg @KarenGhavam-lunarG @asuessenbach @mtavenrath and other interested parties: heads-up that we propose to rename the default branch of this repository to 'main' in late August 2021, following emerging Khronos & github practice (for Khronos members, see internal khronos-general issue 106). This should have very little impact, although if you have a checked-out repository clone, you may want to follow the simple instructions github will pop up on the repository webpage describing how to do the same locally.

If there is a concern about this, please raise it here by 2021-08-23.

Because this repository has many downstream consumers, I expect we'll need to do some internal review to make sure that this change won't be disruptive. Github's renaming tool covers many common use cases transparently (see https://github.com/github/renaming).

Validation layers broken by missing len="descriptorSetCount"

Commit fe98507 removed len="descriptorSetCount" from pSetLayouts in VkDescriptorSetAllocateInfo. This breaks the build for Vulkan Validation Layers and seems like a bug, since descriptorSetCount is indeed the length of the pSetLayouts array

Conflict of 'vulcan_core.h' with C++ 20

VkPipelineShaderStageCreateInfo contains VkShaderModule module field, whose name is a C++ 20 reserved keyword.

Please bring back sdk-1.2.135 branch

When using latest YOCTO release the following happens

09:38:09  ERROR: vulkan-headers-1.2.135.0-r0 do_fetch: Fetcher failure: Unable to find revision fb7f9c9bcd1d1544ea203a1f3d4253d0e90c5a90 in branch sdk-1.2.135 even from upstream
09:38:09  ERROR: vulkan-headers-1.2.135.0-r0 do_fetch: Fetcher failure for URL: 'git://github.com/KhronosGroup/Vulkan-Headers.git;branch=sdk-1.2.135'. Unable to fetch URL from any source.

somehow the branch has been removed (or superseded by sdk-1.2.141).
As YOCTO is very picky about branches (for very good reasons) please bring back the branch.
Also I like to point out that I consider it a bad practice to remove release branches and this is very prone to various downstream errors

Request to move registry/vk.xml to registry/xml/vk.xml

In Vulkan-Hpp/CMakeLists.txt, path to vk.xml in has some inconsistency.
VulkanRegistry_DIR cannot point to Vulkan-Docs, because inside it vk.xml is inside xml directory.
Meanwhile, Vulkan-Hpp CMakeLists.txt expects vk.xml to be found from directory called registry.

One possible solution is to move Vulkan-Headers/registry/vk.xml to Vulkan-Headers/registry/xml/vk.xml.

IMHO it is not ideal that Vulkan-Headers keeps copy of registry from Vulkan-Docs. It could be better to simply use files from Vulkan-Docs directly.

Cross-posted with KhronosGroup/Vulkan-Hpp#793

Documentation error in VkViewport?

Is it right that the minDepth has to be greater than or equal to maxDepth?

VkViewport
"minDepth and maxDepth are the depth range for the viewport. It is valid for minDepth to be greater than or equal to maxDepth."

Found with @baetz-daniel

Avoid windows.h

I consider including windows.h evil and try to avoid it as much as possible. Including it may cause many troubles. And vulkan.h includes it if you specify VK_USE_PLATFORM_WIN32_KHR. The troubles fall into two categories:

1. Polluted namespace by thousands and thousands of symbols, including min, max, near, far and MemoryBarrier macros, making it difficult even to use stl library (e.g. std::max, or std::numeric_limits<uint64_t>::max(), .... - these clashes with above mentioned macros). Even vk_sdk_platform.h have to define NOMINMAX and #undef inline and vulkan.hpp have to #undef MemoryBarrier to fight the problems arising from all this. Using variables like near and far is not possible in your project without further #undefs. Other difficulties are probably waiting just behind the doors.
2. Compilation time is extended. The windows.h includes huge tree of other headers and I would not wonder if it would be the half of the whole WinAPI. Maybe not, but it is quite much. Thus, any vulkan project will compile much longer just because it defines VK_USE_PLATFORM_WIN32_KHR.

Would you be open to consider not including windows.h in vulkan headers? The vulkan.hpp is already doing that even although it calls some WinAPI functions. I was investigating and all that seems to be missing to avoid windows.h are the following typedefs:

typedef struct HINSTANCE__* HINSTANCE;
typedef struct HWND__* HWND;
typedef struct HMONITOR__* HMONITOR;
typedef void* HANDLE;
typedef /*_Null_terminated_*/ const wchar_t *LPCWSTR;
typedef unsigned long DWORD;
typedef struct _SECURITY_ATTRIBUTES SECURITY_ATTRIBUTES;

With these 7 lines, windows.h is no more needed, at least as far as I tested. And all the problems above disappear.

Edit: struct SECURITY_ATTRIBUTES changed to typedef struct _SECURITY_ATTRIBUTES SECURITY_ATTRIBUTES

Vulkan-Hpp planning to split vulkan.hpp into multiple files

Per KhronosGroup/Vulkan-Hpp#979, Vulkan-Hpp is proposing to split vulkan.hpp into several different files. In terms of how it would impact this repository, I'd just change the process for updating the repo to include all those new files. But there are downstream impacts as other repositories consuming this one will need to copy / install all of the new files, not just vulkan.hpp. This is a tracker for getting feedback, particularly from downstream Khronos projects like the https://github.com/KhronosGroup/Vulkan-Loader .

Assigning to @KarenGhavam-lunarG as this is probably largely in LunarG's ballpark in terms of constructing SDKs and whatever internal use of vulkan.hpp your projects have.

redefining CMAKE_INSTALL_PREFIX breaks build

Ignore this. It was a local problem sigh sorry for the noise.

Unspecified extension VK_QNX_screen_surface

I use this xml to auto generate C# binding (https://github.com/WaveEngine/Vulkan.NET) and in the latest version there is an undefined extension VK_QNX_screen_surface.

Here is the extension, but if you search for vkCreateScreenSurfaceQNX or vkGetPhysicalDeviceScreenPresentationSupportQNX, these are not defined in the xml.

<extension name="VK_QNX_screen_surface" number="379" type="instance" requires="VK_KHR_surface" platform="screen" author="QNX" contact="Mike Gorchak @mgorchak-blackberry" supported="disabled"> <require> <enum value="1" name="VK_QNX_SCREEN_SURFACE_SPEC_VERSION"/> <enum value="&quot;VK_QNX_screen_surface&quot;" name="VK_QNX_SCREEN_SURFACE_EXTENSION_NAME"/> <enum offset="0" extends="VkStructureType" name="VK_STRUCTURE_TYPE_SCREEN_SURFACE_CREATE_INFO_QNX"/> <type name="VkScreenSurfaceCreateFlagsQNX"/> <type name="VkScreenSurfaceCreateInfoQNX"/> <command name="vkCreateScreenSurfaceQNX"/> <command name="vkGetPhysicalDeviceScreenPresentationSupportQNX"/> </require> </extension>

VK_NULL_HANDLE issues with Visual Studio 2019

After updating to latest headers I have issue with VK_NULL_HANDLE defined to ((void*)0).

Seams there is an issue with __cplusplus not working correctly and probably should be used _MSVC_LANG similar as vulkan.hpp.

Thanks

tag sdk-1.2.135?

Hi, loader/tools/validationlayers got tagged with sdk-1.2.135 already, shouldn't the headers too?

generator.py broken dependencies

generator.py includes spec_tools.utils, but I can't find that in this repo. It looks like it needs to be synched from the Khronos-private repository.

vulkan.hpp: overwrites its own vkGetInstanceProcAddr with Null, causing crashes

Upstream issue is KhronosGroup/Vulkan-Hpp#1108

The vk::DispatchLoaderDynamic::init(vk::VkInstance) method uses vkGetInstanceProcAddr to overwrite vkGetInstanceProcAddr itself.

See

Vulkan-Headers/include/vulkan/vulkan.hpp

Line 11864 in d594f70

vkGetInstanceProcAddr = PFN_vkGetInstanceProcAddr( vkGetInstanceProcAddr( instance, "vkGetInstanceProcAddr" ) );

But the value is NULL, because a valid 'instance' is provided and so it falls into the last row in the table in 4.1 "Command Function Pointers" https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#initialization-functionpointers

But then that causes a crash in the very next function pointer initialization call.

This bad behaviour was uncovered by a recent fix in the loader: KhronosGroup/Vulkan-Loader#692

Breakage in vulkan-tools and metacity with vulkan-headers-1.2.140

Hello,

in vulkan-headers-1.2.140 the definition of VK_DYNAMIC_STATE_RANGE_SIZE has been removed, which breaks building packages such as vulkan-tools and metacity (and possibly more). Alpine Linux had to revert back to vulkan-headers-1.2.139 for the time being due to that [0].

0: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/7601

Can't build 1.1.111 header update until there's another Hpp fix

FYI mostly for the LunarG folks: we've had some XML / Vulkan-Hpp issues in the previous two updates (109, 110) that were preventing me from doing a Vulkan-Headers update. I believe @mtavenrath has dealt with those, along with an XML fix in 1.1.111, but there's another issue in a recent commit to Vulkan-Hpp which is blocking me from completing a 1.1.111 Vulkan-Headers update. Hopefully we can clear that up soon - it's a relatively minor build issue. See KhronosGroup/Vulkan-Hpp#339

'#define UNICODE' causes issues on Windows

On Hpp Headers of 1.1.126 and 1.1.127 (might have been added earlier though), there is a section where there is a call to LoadLibrary, and the definition of LoadLibrary changes if you have '#define UNICODE' to receiving a wide char array (instead of a char array).
This can be fixed by changing the call to LoadLibrary to LoadLibraryA, or by having a '#ifdef UNICODE' and having the file name as wide char

#elif defined(_WIN32)
    m_library = LoadLibraryA( "vulkan-1.dll" );    
#else

#elif defined(_WIN32)
#ifdef UNICODE
    m_library = LoadLibrary( L"vulkan-1.dll" );
#else
    m_library = LoadLibrary( "vulkan-1.dll" );
#endif
#else

Vulkan-Hpp builds, does not compile in v1.1.109

See PR #58. Compiling a trivial test with clang++ gives this error:

In file included from hpptest.cpp:1:
./vulkan/vulkan.hpp:36506:5: error: constructor cannot be redeclared
    PerformanceValueDataINTEL( Bool32 valueBool_ )
    ^
./vulkan/vulkan.hpp:36491:5: note: previous declaration is here
    PerformanceValueDataINTEL( uint32_t value32_ = 0 )
    ^
./vulkan/vulkan.hpp:54489:31: error: use of undeclared identifier 'result'
    return createResultValue( result, VULKAN_HPP_NAMESPACE_STRING"::Devi...
                              ^
2 errors generated.

The problem is likely related to the fact that this is a union, not a struct, but beyond that I haven't looked into it.

ICD function prototype mismatch using MSVC

It looks like these prototypes were recently added to vk_icd.h

VKAPI_ATTR VkResult VKAPI_CALL vk_icdNegotiateLoaderICDInterfaceVersion(uint32_t* pVersion);
VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL vk_icdGetInstanceProcAddr(VkInstance instance, const char* pName);
VKAPI_ATTR PFN_vkVoidFunction VKAPI_CALL vk_icdGetPhysicalDeviceProcAddr(VkInstance isntance, const char* pName);

I use __declspec(dllexport) in my code, so I get error C2375 about redefining with different linkage. I'm currently using VK_NO_PROTOTYPES to work around this, but maybe there's a better solution.

Fix clang-tidy warnings for [hicpp-signed-bitwise]

Running clang-tidy on some basic Vulkan code emits warnings related to the usage of VK_MAKE_VERSION, VK_API_VERSION_1_X and VK_VERSION_MAJOR/MINOR, due to the usage of bitwise shift operations performed on signed integers:

warning: use of a signed integer operand with a binary bitwise operator [hicpp-signed-bitwise]

vk.xml missing VK_HEADER_VERSION update to 188

Seems that #define <name>VK_HEADER_VERSION</name> 187</type> didn't get updated as it should. This breaks autogen that relied on this macro for defining the version of the header.

Unable to build with recent Vulkan-Headers

If you have the latest Vulkan-Headers and you use it by adding the headers subdirectory first the configure step will fail. This is due to 382bf3d which changed the target_include_directories command to have the BUILD_INTERFACE and INSTALL_INTERFACE.

From my searching around those get evaluated at non-configure time, so when the layers tries to do the FILE command later to determine the headers version we end up with a VulkanHeader_INCLUDE_DIRS with something like:

"/Users/dsinclair/Development/vulkan-validationlayers/$<BUILD_INTERFACE:/Users/dsinclair/Development/vulkan-validationlayers/external/Vulkan-Headers/include>;$<INSTALL_INTERFACE:include>/vulkan/vulkan_core.h"
which doesn't work so well

I'm currently seeing this in the ValidationLayers and in github.com/google/amber and github.com/google/vkb.

VK_COLORSPACE_SRGB_NONLINEAR_KHR

Please Ignore my issue. :D. Just realized afterwards that it is ok.

Vulkan video headers are missing

Build with VK_ENABLE_BETA_EXTENSIONS fails:

include/vulkan/vulkan_beta.h:434:10: fatal error: 'vk_video/vulkan_video_codec_h264std.h' file not found

Are the video headers expected to land soon? I could attempt to remove VK_ENABLE_BETA_EXTENSIONS from VVL's BUILD.gn, but would rather not if this is something that'll be fixed soonish.

vk_patform.h include path in vulkan_core.h is incorrect

On this line:

Vulkan-Headers/include/vulkan/vulkan_core.h

Line 23 in b8c57b0

#include "vulkan/vk_platform.h"

It should be just

#include "vk_platform.h"

since vk_platform.h is already in the same directory.

v.1.2.192 tags points to .191 update commit

@oddhack it looks like the tag created for #229 points to the 1.2.191 update at 4fee3ef, instead of the 1.2.192 update at c519fd7. Can you force-push this tag to point to the correct revision?

Move vulkan.hpp to a different repository

vulkan.hpp is a whopping 3+ MB file with 75k lines. Some projects use it, while others prefer the bare-bones C interface. As such, while it is technically a Vulkan header, it is not an integral part of the Vulkan headers. It's not part of the API. The Vulkan spec states "Vulkan is defined as an API in the C99 language", and describes the C headers but there is no mention of vulkan.hpp. Hence it's an optional wrapper and in my opinion doesn't belong in the Vulkan-Headers repo.

The sheer size of the file makes downloads slower (also affecting CI tests), slows down IDEs parsing/indexing it, and when searching through a whole project it produces a lot of false positives when not actually using this header. Hence I suggest moving it to another repo, e.g. Vulkan-Cpp-Headers (note Vulkan-Hpp already contains it, but I understand not all users of vulkan.hpp want all the samples and tests it contains either).

Renamed without changing it inside the struct. Intended or not?

You rename "VkPipelineStageFlags2KHR" to "VkPipelineStageFlagBits2KHR" and "VkAccessFlags2KHR" to "VkAccessFlagBits2KHR" without changing it inside the struct. Is it intended or will it be changed later?

For example

Vulkan-Headers/include/vulkan/vulkan_core.h

Line 7584 in e1d8c49

typedef VkFlags64 VkPipelineStageFlagBits2KHR;

Vulkan-Headers/include/vulkan/vulkan_core.h

Lines 7672 to 7679 in e1d8c49

	typedef struct VkMemoryBarrier2KHR {
	VkStructureType sType;
	const void* pNext;
	VkPipelineStageFlags2KHR srcStageMask;
	VkAccessFlags2KHR srcAccessMask;
	VkPipelineStageFlags2KHR dstStageMask;
	VkAccessFlags2KHR dstAccessMask;
	} VkMemoryBarrier2KHR;

compilation issue under clang + windows

C:/msys64/home/Mangix/devstuff/MINGW-packages/mingw-w64-vulkan-loader/src/Vulkan-Loader-1.2.166/loader/trampoline.c:768:42: error: redeclaration of 'vkGetPhysicalDeviceMemoryProperties' cannot add 'dllexport' attribute
LOADER_EXPORT VKAPI_ATTR void VKAPI_CALL vkGetPhysicalDeviceMemoryProperties(VkPhysicalDevice physicalDevice,
                                         ^
C:/msys64/clang64/include/vulkan/vulkan_core.h:3303:28: note: previous declaration is here
VKAPI_ATTR void VKAPI_CALL vkGetPhysicalDeviceMemoryProperties(
                           ^
C:/msys64/home/Mangix/devstuff/MINGW-packages/mingw-w64-vulkan-loader/src/Vulkan-Loader-1.2.166/loader/trampoline.c:776:46: error: redeclaration of 'vkCreateDevice' cannot add 'dllexport' attribute
LOADER_EXPORT VKAPI_ATTR VkResult VKAPI_CALL vkCreateDevice(VkPhysicalDevice physicalDevice, const VkDeviceCreateInfo *pCreateInfo,
                                             ^
C:/msys64/clang64/include/vulkan/vulkan_core.h:3315:32: note: previous declaration is here
VKAPI_ATTR VkResult VKAPI_CALL vkCreateDevice(

and many more. The failure happens when compiling vulkan-loader but I think the headers are the problem. They don't add dllexport.

`#define`ing enum values breaks validation layer build

I noticed a build issue when rolling vulkan repos within ANGLE forward. In vulkan_core.h, I see the following:

typedef enum VkFilter {
    VK_FILTER_NEAREST = 0,
    VK_FILTER_LINEAR = 1,
    VK_FILTER_CUBIC_EXT = 1000015000,
    VK_FILTER_BEGIN_RANGE = VK_FILTER_NEAREST,
    VK_FILTER_END_RANGE = VK_FILTER_LINEAR,
    VK_FILTER_RANGE_SIZE = (VK_FILTER_LINEAR - VK_FILTER_NEAREST + 1),
    VK_FILTER_MAX_ENUM = 0x7FFFFFFF
} VkFilter;

...

#define VK_FILTER_CUBIC_EXT               1000015000

In parameter_validation.cpp generated by the validation layers, there is a line that reads:

const std::vector<VkFilter> AllVkFilterEnums = {VK_FILTER_NEAREST, VK_FILTER_LINEAR, VK_FILTER_CUBIC_EXT, };

This causes a build error, where the mixture {VkFilter, VkFilter, int} is causing the compiler to not be able to match the appropriate constructor of the vector. I can verify this is really the issue by casting the third parameter to VkFilter which resolves the compile error:

const std::vector<VkFilter> AllVkFilterEnums = {VK_FILTER_NEAREST, VK_FILTER_LINEAR, (VkFilter)VK_FILTER_CUBIC_EXT, };

The issue is that vulkan_core.h is defining VK_FILTER_CUBIC_EXT twice, once correctly in the VkFilter enum and another time as an int-typed number through a define.

---

My suggestions are to either not #define the constants that are already added to the enums, or if necessary (for example to later test #ifdef VK_FILTER_CUBIC_EXT), define them cast properly to the type:

#define VK_FILTER_CUBIC_EXT               ((VkFilter)1000015000)

Vulkan

Update repository for Vulkan 1.2.138/1.2.139

This repository is currently on version 1.2.137 and has been out of date for ~11 days.

Is there any reason why it is not being updated?

vulkan_screen.h was generated, but it's missing in the repository

Hi,

I see that all QNX stuff was properly generated, but new generated header vulkan_screen.h was not added to the repository.

Thanks!

Deploy tags when there are new releases

Hi, I noticed that you detail the version number in the commit comments, but you haven't bothered to add a new tag, I'd like to request you add a new tag for every new release that gets covered in the commits.

vk_video/vulkan_video_codec_h265std_encode.h missing from repo

The header is included in vulkan/vulkan_beta.h but is not present in the repo.

How to manage expected Vulkan-Hpp breakage this week?

@shannon-lunarg @mark-lunarg @nsubtil @mtavenrath I think it's nearly certain there will be breakage of Vulkan-Hpp when I try to build the update to this repo for the next Vulkan-Docs update. There are at least two, and maybe three MRs going into that which break hpp-generate in CI.

How do you want to handle this? My expectation is that I'll update a branch of this repo as best I can and then create an MR, but not merge it until the build issues are resolved. Unfortunately Vulkan-Docs has a variety of downstream dependencies now that can and do get broken on a fairly regular basis, and fixing them is outside the direct control of the Vulkan Working Group. The specific thing that will be annoying in this case is that there are a variety of new extensions going into this update, and until we can update Vulkan-Headers with at least the C headers, nobody will be able to use those extensions.

Update Vulkan-Headers with new headers from Vulkan-Hpp

Please get the following files from Vulkan-Hpp into Vulkan-Headers:

vulkan.hpp
vulkan_enums.hpp
vulkan_funcs.hpp
vulkan_handles.hpp
vulkan_structs.hpp

'module' is a reserved keyword in c++20

module is used as an identifier in vulkan.h, namely in VkPipelineShaderStageCreateInfo.

This is a keyword in C++ 20 and should be changed.

Upcoming hpp-generate problem with internal branch

In internal branch 977-refactor, Vulkan-Hpp is failing with the warning

caught exception: Spec error on line 179: missing required element <type>

I believe the responsible line is line 179 in vk.xml in that branch, which is

<type category="basetype">struct <name>ANativeWindow</name>;</type>

Note this got moved from a 'define' category to a 'basetype' category in this MR.

We're planning to include this MR in the next spec update for Sunday evening, so it would be great if you could accommodate this usage in Vulkan-Hpp before then. Thanks!

includes target "X" which requires target "Vulkan-Headers" that is not in any export set.

Currently I am looking to use Vulkan Headers directly from the repo, but it seems when I include with target_link_library I get the error includes target "X" which requires target "Vulkan-Headers" that is not in any export set. Is there a reason to not include an export of the vulkan-header targets? Or is there a different suggested way to add vulkan headers as part of a target that will be exported?

vulkan.hpp conflicts with C++ library headers

$ cat a.cc
#define VK_USE_PLATFORM_DISPLAY_KHR
#include <vulkan/vulkan.hpp>

int main()
{
    vk::PhysicalDevice gpu;
    uint32_t display_count;
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
    return 0;
}

Clang/libc++ 10

$ clang++10 a.cc
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:37:
In file included from /usr/include/c++/v1/algorithm:643:
/usr/include/c++/v1/memory:1549:22: error: type
      'std::__1::allocator_traits<unsigned int *>::allocator_type'
      (aka 'unsigned int *') cannot be used prior to '::' because it has no
      members
    typedef typename allocator_type::value_type value_type;
                     ^
/usr/include/c++/v1/vector:331:22: note: in instantiation of template class
      'std::__1::allocator_traits<unsigned int *>' requested here
    typedef typename __alloc_traits::size_type       size_type;
                     ^
/usr/include/c++/v1/vector:470:15: note: in instantiation of template class
      'std::__1::__vector_base<vk::DisplayPropertiesKHR, unsigned int *>'
      requested here
    : private __vector_base<_Tp, _Allocator>
              ^
a.cc:8:9: note: in instantiation of template class
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>' requested
      here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:480:30: error: 'reference' is a protected member of
      'std::__1::__vector_base<vk::DisplayPropertiesKHR, unsigned int *>'
    typedef typename __base::reference               reference;
                             ^
a.cc:8:9: note: in instantiation of template class
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>' requested
      here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
/usr/include/c++/v1/vector:334:54: note: declared protected here
    typedef value_type&                              reference;
                                                     ^
/usr/include/c++/v1/vector:481:30: error: 'const_reference' is a protected
      member of 'std::__1::__vector_base<vk::DisplayPropertiesKHR, unsigned int
      *>'
    typedef typename __base::const_reference         const_reference;
                             ^
/usr/include/c++/v1/vector:335:54: note: declared protected here
    typedef const value_type&                        const_reference;
                                                     ^
/usr/include/c++/v1/vector:483:30: error: 'difference_type' is a protected
      member of 'std::__1::__vector_base<vk::DisplayPropertiesKHR, unsigned int
      *>'
    typedef typename __base::difference_type         difference_type;
                             ^
/usr/include/c++/v1/vector:336:54: note: declared protected here
    typedef typename __alloc_traits::difference_type difference_type;
                                                     ^
/usr/include/c++/v1/vector:484:30: error: 'pointer' is a protected member of
      'std::__1::__vector_base<vk::DisplayPropertiesKHR, unsigned int *>'
    typedef typename __base::pointer                 pointer;
                             ^
/usr/include/c++/v1/vector:337:54: note: declared protected here
    typedef typename __alloc_traits::pointer         pointer;
                                                     ^
/usr/include/c++/v1/vector:485:30: error: 'const_pointer' is a protected member
      of 'std::__1::__vector_base<vk::DisplayPropertiesKHR, unsigned int *>'
    typedef typename __base::const_pointer           const_pointer;
                             ^
/usr/include/c++/v1/vector:338:54: note: declared protected here
    typedef typename __alloc_traits::const_pointer   const_pointer;
                                                     ^
/usr/include/c++/v1/vector:491:37: error: type
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::allocator_type' (aka 'unsigned int *') cannot be used prior to '::'
      because it has no members
    static_assert((is_same<typename allocator_type::value_type, value_ty...
                                    ^
In file included from a.cc:2:
/usr/include/vulkan/vulkan.hpp:81999:38: error: member reference base type
      'const nullptr_t' is not a structure or union
  ...= static_cast<Result>( d.vkGetPhysicalDeviceDisplayPropertiesKHR( m_phys...
                            ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
/usr/include/vulkan/vulkan.hpp:82003:40: error: member reference base type
      'const nullptr_t' is not a structure or union
  ...= static_cast<Result>( d.vkGetPhysicalDeviceDisplayPropertiesKHR( m_phys...
                            ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:507:11: error: type
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>::__base' (aka
      '__vector_base<vk::DisplayPropertiesKHR, unsigned int *>') is not a direct
      or virtual base of 'std::__1::vector<vk::DisplayPropertiesKHR, unsigned
      int *>'
        : __base(__a)
          ^~~~~~
/usr/include/vulkan/vulkan.hpp:81994:49: note: in instantiation of member
      function 'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::vector' requested here
    std::vector<DisplayPropertiesKHR,Allocator> properties( vectorAllocator );
                                                ^
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:2024:39: error: no member named '__begin_' in
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>'
        this->__destruct_at_end(this->__begin_ + __sz);
                                ~~~~  ^
/usr/include/vulkan/vulkan.hpp:82002:20: note: in instantiation of member
      function 'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::resize' requested here
        properties.resize( propertyCount );
                   ^
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:1087:38: error: no member named '__end_cap' in
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>'
    if (static_cast<size_type>(this->__end_cap() - this->__end_) >= __n)
                               ~~~~  ^
/usr/include/c++/v1/vector:2022:15: note: in instantiation of member function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>::__append'
      requested here
        this->__append(__sz - __cs);
              ^
/usr/include/vulkan/vulkan.hpp:82002:20: note: in instantiation of member
      function 'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::resize' requested here
        properties.resize( propertyCount );
                   ^
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:833:17: error: call to non-static member function
      without an object argument
        __base::__destruct_at_end(__new_last);
        ~~~~~~~~^~~~~~~~~~~~~~~~~
/usr/include/c++/v1/vector:2024:15: note: in instantiation of member function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::__destruct_at_end' requested here
        this->__destruct_at_end(this->__begin_ + __sz);
              ^
/usr/include/vulkan/vulkan.hpp:82002:20: note: in instantiation of member
      function 'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::resize' requested here
        properties.resize( propertyCount );
                   ^
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:833:17: error: '__destruct_at_end' is a protected
      member of 'std::__1::__vector_base<vk::DisplayPropertiesKHR, unsigned int
      *>'
        __base::__destruct_at_end(__new_last);
                ^
/usr/include/c++/v1/vector:375:10: note: declared protected here
    void __destruct_at_end(pointer __new_last) _NOEXCEPT;
         ^
/usr/include/c++/v1/vector:698:43: error: no member named '__begin_' in
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>'
        {return _VSTD::__to_address(this->__begin_);}
                                    ~~~~  ^
/usr/include/c++/v1/vector:891:39: note: in instantiation of member function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>::data'
      requested here
      __annotate_contiguous_container(data(), data() + capacity(),
                                      ^
/usr/include/c++/v1/vector:834:9: note: in instantiation of member function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::__annotate_shrink' requested here
        __annotate_shrink(__old_size);
        ^
/usr/include/c++/v1/vector:2024:15: note: in instantiation of member function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::__destruct_at_end' requested here
        this->__destruct_at_end(this->__begin_ + __sz);
              ^
/usr/include/vulkan/vulkan.hpp:82002:20: note: in instantiation of member
      function 'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::resize' requested here
        properties.resize( propertyCount );
                   ^
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:659:25: error: call to non-static member function
      without an object argument
        {return __base::capacity();}
                ~~~~~~~~^~~~~~~~
/usr/include/c++/v1/vector:891:56: note: in instantiation of member function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>::capacity'
      requested here
      __annotate_contiguous_container(data(), data() + capacity(),
                                                       ^
/usr/include/c++/v1/vector:834:9: note: in instantiation of member function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::__annotate_shrink' requested here
        __annotate_shrink(__old_size);
        ^
/usr/include/c++/v1/vector:2024:15: note: in instantiation of member function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::__destruct_at_end' requested here
        this->__destruct_at_end(this->__begin_ + __sz);
              ^
/usr/include/vulkan/vulkan.hpp:82002:20: note: in instantiation of member
      function 'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::resize' requested here
        properties.resize( propertyCount );
                   ^
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:659:25: error: 'capacity' is a protected member of
      'std::__1::__vector_base<vk::DisplayPropertiesKHR, unsigned int *>'
        {return __base::capacity();}
                        ^
/usr/include/c++/v1/vector:371:15: note: declared protected here
    size_type capacity() const _NOEXCEPT
              ^
/usr/include/c++/v1/vector:656:46: error: no member named '__end_' in
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>'
        {return static_cast<size_type>(this->__end_ - this->__begin_);}
                                       ~~~~  ^
/usr/include/vulkan/vulkan.hpp:82008:54: note: in instantiation of member
      function
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>::size'
      requested here
      VULKAN_HPP_ASSERT( propertyCount <= properties.size() );
                                                     ^
/usr/include/vulkan/vulkan.hpp:61:30: note: expanded from macro
      'VULKAN_HPP_ASSERT'
# define VULKAN_HPP_ASSERT   assert
                             ^
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
In file included from a.cc:2:
In file included from /usr/include/vulkan/vulkan.hpp:56:
/usr/include/c++/v1/vector:1287:30: error: no member named '__alloc' in
      'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int *>'
    : __base(_VSTD::move(__x.__alloc()))
                         ~~~ ^
/usr/include/vulkan/vulkan.hpp:82011:12: note: in instantiation of member
      function 'std::__1::vector<vk::DisplayPropertiesKHR, unsigned int
      *>::vector' requested here
    return createResultValue( result, properties, VULKAN_HPP_NAMESPACE_S...
           ^
a.cc:8:9: note: in instantiation of function template specialization
      'vk::PhysicalDevice::getDisplayPropertiesKHR<unsigned int *, nullptr_t>'
      requested here
    gpu.getDisplayPropertiesKHR(&display_count, nullptr);
        ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.

GCC/libstdc++ 9

$ g++9 a.cc
In file included from /usr/lib/gcc9/include/c++/vector:67,
                 from /usr/include/vulkan/vulkan.hpp:56,
                 from a.cc:2:
/usr/lib/gcc9/include/c++/bits/stl_vector.h: In instantiation of 'struct std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>':
/usr/lib/gcc9/include/c++/bits/stl_vector.h:386:11:   required from 'class std::vector<vk::DisplayPropertiesKHR, unsigned int*>'
a.cc:8:56:   required from here
/usr/lib/gcc9/include/c++/bits/stl_vector.h:84:21: error: 'unsigned int*' is not a class, struct, or union type
   84 |  rebind<_Tp>::other _Tp_alloc_type;
      |                     ^~~~~~~~~~~~~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h:86:9: error: 'unsigned int*' is not a class, struct, or union type
   86 |         pointer;
      |         ^~~~~~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h: In instantiation of 'class std::vector<vk::DisplayPropertiesKHR, unsigned int*>':
a.cc:8:56:   required from here
/usr/lib/gcc9/include/c++/bits/stl_vector.h:471:20: error: no members matching 'std::vector<vk::DisplayPropertiesKHR, unsigned int*>::_Base {aka std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>}::_M_allocate' in 'std::vector<vk::DisplayPropertiesKHR, unsigned int*>::_Base' {aka 'struct std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>'}
  471 |       using _Base::_M_allocate;
      |                    ^~~~~~~~~~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h:472:20: error: no members matching 'std::vector<vk::DisplayPropertiesKHR, unsigned int*>::_Base {aka std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>}::_M_deallocate' in 'std::vector<vk::DisplayPropertiesKHR, unsigned int*>::_Base' {aka 'struct std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>'}
  472 |       using _Base::_M_deallocate;
      |                    ^~~~~~~~~~~~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h:474:20: error: no members matching 'std::vector<vk::DisplayPropertiesKHR, unsigned int*>::_Base {aka std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>}::_M_get_Tp_allocator' in 'std::vector<vk::DisplayPropertiesKHR, unsigned int*>::_Base' {aka 'struct std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>'}
  474 |       using _Base::_M_get_Tp_allocator;
      |                    ^~~~~~~~~~~~~~~~~~~
In file included from a.cc:2:
/usr/include/vulkan/vulkan.hpp: In instantiation of 'typename vk::ResultValueType<std::vector<vk::DisplayPropertiesKHR, Allocator> >::type vk::PhysicalDevice::getDisplayPropertiesKHR(const Allocator&, const Dispatch&) const [with Allocator = unsigned int*; Dispatch = std::nullptr_t; typename vk::ResultValueType<std::vector<vk::DisplayPropertiesKHR, Allocator> >::type = std::vector<vk::DisplayPropertiesKHR, unsigned int*>]':
a.cc:8:56:   required from here
/usr/include/vulkan/vulkan.hpp:81999:39: error: request for member 'vkGetPhysicalDeviceDisplayPropertiesKHR' in 'd', which is of non-class type 'std::nullptr_t'
81999 |       result = static_cast<Result>( d.vkGetPhysicalDeviceDisplayPropertiesKHR( m_physicalDevice, &propertyCount, nullptr ) );
      |                                     ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/vulkan/vulkan.hpp:82003:41: error: request for member 'vkGetPhysicalDeviceDisplayPropertiesKHR' in 'd', which is of non-class type 'std::nullptr_t'
82003 |         result = static_cast<Result>( d.vkGetPhysicalDeviceDisplayPropertiesKHR( m_physicalDevice, &propertyCount, reinterpret_cast<VkDisplayPropertiesKHR*>( properties.data() ) ) );
      |                                       ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/lib/gcc9/include/c++/vector:67,
                 from /usr/include/vulkan/vulkan.hpp:56,
                 from a.cc:2:
/usr/lib/gcc9/include/c++/bits/stl_vector.h: In instantiation of 'std::vector<_Tp, _Alloc>::~vector() [with _Tp = vk::DisplayPropertiesKHR; _Alloc = unsigned int*]':
a.cc:8:56:   required from here
/usr/lib/gcc9/include/c++/bits/stl_vector.h:677:30: error: 'struct std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>::_Vector_impl' has no member named '_M_start'
  677 |  std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
      |                ~~~~~~~~~~~~~~^~~~~~~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h:677:54: error: 'struct std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>::_Vector_impl' has no member named '_M_finish'
  677 |  std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
      |                                        ~~~~~~~~~~~~~~^~~~~~~~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h:678:28: error: '_M_get_Tp_allocator' was not declared in this scope; did you mean 'get_allocator'?
  678 |         _M_get_Tp_allocator());
      |         ~~~~~~~~~~~~~~~~~~~^~
      |         get_allocator
/usr/lib/gcc9/include/c++/bits/stl_vector.h: In instantiation of 'std::_Vector_base<_Tp, _Alloc>::_Vector_base(const allocator_type&) [with _Tp = vk::DisplayPropertiesKHR; _Alloc = unsigned int*; std::_Vector_base<_Tp, _Alloc>::allocator_type = unsigned int*]':
/usr/lib/gcc9/include/c++/bits/stl_vector.h:495:18:   required from 'std::vector<_Tp, _Alloc>::vector(const allocator_type&) [with _Tp = vk::DisplayPropertiesKHR; _Alloc = unsigned int*; std::vector<_Tp, _Alloc>::allocator_type = unsigned int*]'
/usr/include/vulkan/vulkan.hpp:81994:49:   required from 'typename vk::ResultValueType<std::vector<vk::DisplayPropertiesKHR, Allocator> >::type vk::PhysicalDevice::getDisplayPropertiesKHR(const Allocator&, const Dispatch&) const [with Allocator = unsigned int*; Dispatch = std::nullptr_t; typename vk::ResultValueType<std::vector<vk::DisplayPropertiesKHR, Allocator> >::type = std::vector<vk::DisplayPropertiesKHR, unsigned int*>]'
a.cc:8:56:   required from here
/usr/lib/gcc9/include/c++/bits/stl_vector.h:291:20: error: no matching function for call to 'std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>::_Vector_impl::_Vector_impl(unsigned int* const&)'
  291 |       : _M_impl(__a) { }
      |                    ^
/usr/lib/gcc9/include/c++/bits/stl_vector.h:140:2: note: candidate: 'std::_Vector_base<_Tp, _Alloc>::_Vector_impl::_Vector_impl(std::_Vector_base<_Tp, _Alloc>::_Vector_impl&&) [with _Tp = vk::DisplayPropertiesKHR; _Alloc = unsigned int*]'
  140 |  _Vector_impl(_Vector_impl&& __x) noexcept
      |  ^~~~~~~~~~~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h:140:30: note:   no known conversion for argument 1 from 'const allocator_type' {aka 'unsigned int* const'} to 'std::_Vector_base<vk::DisplayPropertiesKHR, unsigned int*>::_Vector_impl&&'
  140 |  _Vector_impl(_Vector_impl&& __x) noexcept
      |               ~~~~~~~~~~~~~~~^~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h:128:2: note: candidate: 'std::_Vector_base<_Tp, _Alloc>::_Vector_impl::_Vector_impl() [with _Tp = vk::DisplayPropertiesKHR; _Alloc = unsigned int*]'
  128 |  _Vector_impl() _GLIBCXX_NOEXCEPT_IF(
      |  ^~~~~~~~~~~~
/usr/lib/gcc9/include/c++/bits/stl_vector.h:128:2: note:   candidate expects 0 arguments, 1 provided

KHR function in NV codeblock

PFN_vkGetRayTracingShaderGroupHandlesKHR in vulkan_core.h line 10264 is within the NV vendor function block. This could be a bit confusing.

Breaking changes in the 1.2.162 headers.

The 1.2.162 headers contain breaking changes that remove all the enums for the provisional ray-tracing extension. This makes it extremely painful to roll the headers in existing projects because it prevents gradual migration to the new API (even just compilation-wise). This gets even worse for projects that have dependencies that use use the enums from the provisional extension (like the VVL).

Can the WG consider using a _PROVISIONAL_ naming scheme next time and if it wants to remove the enums consider deprecating them over time (like ~a year)?

Something crazy happened, C++20 need help

Can't run cmake on Windows 10 with Visual Studio 2017

UPDATE: Updated to cmake 3.15.5 and all set. Please close this issue although you may want to raise the version requirement from 3.10.2 so others don't run afoul of this.

I'm trying to build on Windows as a prereq for the Vulkan Loader.

Following the build instructions:

On version 3.10.2 of CMake.
Cloned latest code
mkdir build
cd build
cmake ..

The default generator comes up correctly as Visual Studio 15 2017.
However, it errors out:

C:\code\Vulkan-Headers\build>cmake ..
-- Building for: Visual Studio 15 2017
CMake Error at CMakeLists.txt:24 (project):
Failed to run MSBuild command:

MSBuild.exe

to get the value of VCTargetsPath:

The system cannot find the file specified

-- Configuring incomplete, errors occurred!
See also "C:/code/Vulkan-Headers/build/CMakeFiles/CMakeOutput.log".

Not much in log file:
The system is: Windows - 10.0.17134 - AMD64

I did a repair reinstall of VS 2017 but same issue.

linker errors caused by vk::Instance::createDebugUtilsMessengerEXTUnique and vk::Instance::createDebugUtilsMessengerEXT

/usr/bin/ld: CMakeFiles/engine.dir/src/main.cpp.o: in function `main':
main.cpp:(.text.startup+0x25a): undefined reference to `vkCreateDebugUtilsMessengerEXT'
/usr/bin/ld: main.cpp:(.text.startup+0x276): undefined reference to `vkDestroyDebugUtilsMessengerEXT'
collect2: error: ld returned 1 exit status

to reproduce: call instance->createDebugUtilsMessengerEXTUnique with valid arguments

vulkan.hpp - missing return in createResultValue

By the looks of it in vulkan.hpp there is return missing in createResultValue( Result result, char const * message ) if exceptions are enabled.

Vulkan

😊