Error when compiling with Windows 10 SDK 10.0.14393.0 #6460
Comments
|
Are you using VS2015 Update 3? constexpr was implemented in RTM but then tons of fixes came in Updates. Update 3 being the most updated one. You can alternatively install:
|
yes |
|
Its pretty grumpy on checked |
|
@benaadams hmm.. I will try Debug |
|
Release is happy; still trying to workout how to get checked to build though :( |
|
@omariom am having same issue with VS Enterprise and
|
|
@omariom stash a copy of nuget the copy try a Seems to be working for me so far |
|
@benaadams
I will try later today. Thanks. |
|
@omariom, I tested on a VM which has only VS2015 Update 3 installed and SDK 14393 and it failed. I think if we have only VS "15" Preview 3 installed, that would compile it. Or the way @benaadams is suggesting. Or make cmake pick up VS "15" Preview 3 when VS2015 Update 3 is also installed. Seems like the new SDK headers have C++11/14 code which VS2015 can't compile. Note that the nuget package grabs the most recent nightly build from VC team. |
|
Still have an issue, is different though |
|
But I produced a |
|
@benaadams, I have known some related issues around template resolution in recent versions of CL, but I can't seem repro that error with class A{};
class B{};
template<typename TYPE, typename BASE>
class BaseHolder : protected BASE{};
class NewCCWHolder : public BaseHolder<A, B>
{
public:
NewCCWHolder(int p) {}
};
void LogSpew(int facility, int level, const char *fmt, ... ) {
return;
}
bool LoggingEnabled() { return true; }
#define LOG(x) do { if (LoggingEnabled()) { LogSpew x; } } while (0)
struct OBJECTHANDLE__
{
void* unused;
};
typedef struct OBJECTHANDLE__* OBJECTHANDLE;
int main()
{
OBJECTHANDLE oh = nullptr;
NewCCWHolder pStartWrapper(1);
LOG((1, 1, "ComCallWrapper::CopyFromTemplate on Object %8.8x, Wrapper %8.8x\n", oh, pStartWrapper));
}I was thinking of logging the bug upstream.. https://connect.microsoft.com/VisualStudio/feedback, but this code compiles. |
|
Just to be clear, are these |
|
@pgavlin, yes with SDK v10.0.14393.0 headers. It seems like we need latest VC bits to make it compile CoreCLR. |
And you're able to compile other C++ examples with the lastest SDK headers and older VC bits? I ask only b/c the issue mentiones |
|
@pgavlin its definitely the sdk headers not coreclr itself; and when compiling checked rather than release (Release compiles fine) |
Okay, great. Are you able to compile code outside CoreCLR with the relevant SDK and older tools? I'm wondering if this is going to end up having a wider impact... |
|
@pgavlin, at least the hello world with SDK headers compile: #include <stdio.h>
#include <stdlib.h>
#include <windows.h>
#include "c:\program files (x86)\windows kits\10\include\10.0.14393.0\um\shlwapi.h"
int main(int argc, char **argv)
{
fprintf(stderr,"\nHello World\n");
return 0;
}but compiling CoreCLR fails with:
This is VS2015 Update 3 with SDK 14393. Then I grabbed latest VC bits and followed @benaadams' approach: nuget install VisualCppTools -source http://vcppdogfooding.azurewebsites.net/nuget/ -Prerelease
# backup
mkdir "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\temp"
mv "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin" "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\temp"
mv "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include" "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\temp"
mv "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib" "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\temp"
# copy latest VCR
cp -r VisualCppTools.14.0.24405-Pre\lib\native\* "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC"and then in coreclr dir |
|
@jasonwilliams200OK if you do a checked build of your hello world? (not sure how to do checked builds manually, maybe |
|
@jasonwilliams200OK what is the code at c:\program files (x86)\windows kits\10\include\10.0.14393.0\um\shlwapi.h(1764)? I have seen problems when attempting to use |
|
@pgavlin, here is shlwapi.h line 1764: https://gist.github.com/jasonwilliams200OK/66d72219f6657bfe1a1e4e235d76f26e#file-shlwapi-h-L1764 |
|
@pgavlin, and from #if _MSC_VER >= 1900
#define _ENUM_FLAG_CONSTEXPR constexpr
#else
#define _ENUM_FLAG_CONSTEXPR
#endif
#define DEFINE_ENUM_FLAG_OPERATORS(ENUMTYPE) \
extern "C++" { \
inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator | (ENUMTYPE a, ENUMTYPE b) throw() { return ENUMTYPE(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a) | ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \
inline ENUMTYPE &operator |= (ENUMTYPE &a, ENUMTYPE b) throw() { return (ENUMTYPE &)(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type &)a) |= ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \
inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator & (ENUMTYPE a, ENUMTYPE b) throw() { return ENUMTYPE(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a) & ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \
inline ENUMTYPE &operator &= (ENUMTYPE &a, ENUMTYPE b) throw() { return (ENUMTYPE &)(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type &)a) &= ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \
inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator ~ (ENUMTYPE a) throw() { return ENUMTYPE(~((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a)); } \
inline _ENUM_FLAG_CONSTEXPR ENUMTYPE operator ^ (ENUMTYPE a, ENUMTYPE b) throw() { return ENUMTYPE(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)a) ^ ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \
inline ENUMTYPE &operator ^= (ENUMTYPE &a, ENUMTYPE b) throw() { return (ENUMTYPE &)(((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type &)a) ^= ((_ENUM_FLAG_SIZED_INTEGER<ENUMTYPE>::type)b)); } \
}
#else
#define DEFINE_ENUM_FLAG_OPERATORS(ENUMTYPE) // NOP, C allows these operators.
#endif |
|
Okay, this looks like it very well could be a problem with the |
|
@pgavlin, disabling the macro (changing |
|
cc @jkotas. This is going to be a pretty significant issue once TFS builds have moved to newer versions of MSVC and we are able to use |
|
@vinnyrom There is a break building CoreCLR with latest C++ / WinSDK combo. Is it something that you are planning to fix? |
|
@pgavlin, I am just realizing that you asked me to disable the Yes it builds when I commented out |
|
@benaadams, |
|
Can this be fixed by marking the helper methods in |
|
@jkotas, it gives the same error:
C:\Users\Peter\Source\Repos\coreclr [master ≡ +0 ~1 -0 !]> git diff
diff --git a/src/inc/debugreturn.h b/src/inc/debugreturn.h
index cc5bdeb..2a012fb 100644
--- a/src/inc/debugreturn.h
+++ b/src/inc/debugreturn.h
@@ -63,8 +63,13 @@
//
class __SafeToReturn {
public:
+#if _MSC_VER >= 1900
+ static constexpr int safe_to_return() {return 0;};
+ static constexpr int used() {return 0;};
+#else
static int safe_to_return() {return 0;};
static int used() {return 0;};
+#endif
};
class __YouCannotUseAReturnStatementHere { |
|
Hmm, would adding |
Yup it helps, but then it gives errors from other headers such as:
It complains about However, with this change, it works: diff --git a/src/inc/debugreturn.h b/src/inc/debugreturn.h
index cc5bdeb..a5e77ac 100644
--- a/src/inc/debugreturn.h
+++ b/src/inc/debugreturn.h
@@ -93,7 +93,11 @@ typedef __SafeToReturn __ReturnOK;
// build. (And, in fastchecked, there is no penalty at all.)
//
#ifdef _MSC_VER
+#if _MSC_VER < 1900
#define return if (0 && __ReturnOK::safe_to_return()) { } else return
+#else // _MSC_VER < 1900
+#define return return
+#endif // _MSC_VER < 1900
#else // _MSC_VER
#define return for (;1;__ReturnOK::safe_to_return()) return
#endif // _MSC_VER |
|
We could ifdef the SDK version like: #ifdef _MSC_VER
#include <ntverp.h>
#if VER_PRODUCTBUILD < 10011
#define return if (0 && __ReturnOK::safe_to_return()) { } else return
#else // VER_PRODUCTBUILD > 10011
#define return return
#endif // VER_PRODUCTBUILD > 10011but that gives redefinition error as VER_PRODUCTBUILD and many others defined in @jkotas, should we just mark it in documentation that to build with SDK v10.0.14393.0, one needs to have |
Sounds good. Even better would be to add a check for it somewhere that prints nice message when you try to build with the problematic combination ... people do not read documentation. |
|
@jkotas, why is the Windows build.cmd doesn't use cmake configurations? I added a cmake check but cmake configuration never runs and build fails. How are we doing autoconfig in case of Windows? Should I instead detect the SDK in cmd? 😓 |
It was not needed so far...
I think it would be easiest to detect in inc\debugreturn.h. Something like: |
|
I would suggest the following change to debugreturn.h: Replace: |
|
I'm seeing this again, on a machine with SDK v10.0.14393.0, on which _MSC_FULL_VER is 190024213. I don't know what update brought me to that _MSC_FULL_VER; when I look at "Installed Updates" under VS 2015, I see "Visual Studio 2015 Update 3 (KB3022398)"/Version 14.0.25420 and "Update for Microsot Visual Studio 2015 (KB3165756)"/Version 14.0.25425. VS Help > About reports "Version 14.0.25425.01 Update 3". All that sounds the same as what others saw before on this thread. When I run I don't see So it seems that version |
|
You should use _MSC_FULL_VER <= 190024315. Pre-release builds after that (July 19th) support C++14 constexpr. 24213 is a pre-release build from June 14th. -Vinny From: Joseph Tremoulet [mailto:notifications@github.com] I'm seeing this again, on a machine with SDK v10.0.14393.0, on which _MSC_FULL_VER is 190024213. I don't know what update brought me to that _MSC_FULL_VER; when I look at "Installed Updates" under VS 2015, I see "Visual Studio 2015 Update 3 (KB3022398)"/Version 14.0.25420 and "Update for Microsot Visual Studio 2015 (KB3165756)"/Version 14.0.25425. VS Help > About reports "Version 14.0.25425.01 Update 3". All that sounds the same as what others saw before on this thread. When I run cl -Bv, however, I see: Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24213.1 for x86 Copyright (C) Microsoft Corporation. All rights reserved. Compiler Passes: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.exe: Version 19.00.24213.1 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\c1.dll: Version 19.00.24213.1 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\c1xx.dll: Version 19.00.24213.1 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\c2.dll: Version 19.00.24213.1 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\link.exe: Version 14.00.24213.1 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\mspdb140.dll: Version 14.00.24210.0 C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\1033\clui.dll: Version 19.00.24213.1 I don't see cl -Bv output reported in the prior discussion on this thread, but presumably people had version 19.00.24210.?. So it seems that version 19.00.24213 has been released and doesn't include the prerelease changes that fix the constexpr handling; would the appropriate fix then be to change the 190024210 in the version check in debugreturn.h to 190024213? — |
Previously the code was comparing against 190024210 (VS2015 Update 3). Update it to instead compare against 190024315, the last pre-release build before C++14 constexpr support got added; this fixes compilation using pre-release MSVC compilers between 24210 and 24315. Fixes #6642.
Previously the code was comparing against 190024210 (VS2015 Update 3). Update it to instead compare against 190024315, the last pre-release build before C++14 constexpr support got added; this fixes compilation using pre-release MSVC compilers between 24210 and 24315. Fixes #6642.
Previously the code was comparing against 190024210 (VS2015 Update 3). Update it to instead compare against 190024315, the last pre-release build before C++14 constexpr support got added; this fixes compilation using pre-release MSVC compilers between 24210 and 24315. Fixes #6642.
ghost
locked as resolved and limited conversation to collaborators
Almost two thousand errors complaining about
constexpr.The text was updated successfully, but these errors were encountered: