Windows App SDK 1.7.3：`base.h` `#elif _DEBUG` gives build error C1017: invalid integer constant expression

[shelllet]

Describe the bug

#define CPPWINRT_VERSION "2.0.250303.1"

#if !defined(__cpp_lib_source_location) || defined(WINRT_NO_SOURCE_LOCATION)
// Case1: cpp17 mode. The source_location intrinsics are not available.
// Case2: The caller has disabled source_location support. Ensure that there is no binary size overhead for line/file/function.
#define WINRT_IMPL_BUILTIN_LINE 0
#define WINRT_IMPL_BUILTIN_FILE nullptr
#define WINRT_IMPL_BUILTIN_FUNCTION nullptr
#elif defined(_DEBUG)
// cpp20 _DEBUG builds include function information, which has a heavy binary size impact, in addition to file/line.
#define WINRT_IMPL_BUILTIN_LINE __builtin_LINE()
#define WINRT_IMPL_BUILTIN_FILE __builtin_FILE()
#define WINRT_IMPL_BUILTIN_FUNCTION __builtin_FUNCTION()
#else
// Release builds in cpp20 mode get file and line information but NOT function information. Function strings
// quickly add up to a substantial binary size impact, especially when templates are heavily used.
#define WINRT_IMPL_BUILTIN_LINE __builtin_LINE()
#define WINRT_IMPL_BUILTIN_FILE __builtin_FILE()
#define WINRT_IMPL_BUILTIN_FUNCTION nullptr
#endif

Steps to reproduce the bug

_DEBUG is defined, but in a way that doesn't resolve to a valid integer constant expression:

_DEBUG;%(PreprocessorDefinitions)

Expected behavior

No response

Screenshots

No response

NuGet package version

Windows App SDK 1.7.3: 1.7.250606001

Packaging type

Unpackaged

Windows version

Windows 11 version 24H2 (22621, October 2024 Update)

IDE

No response

Additional context

No response

[DarranRowe]

The CppWinRT repository is here.

[DarranRowe]

Also,

_DEBUG is defined, but in a way that doesn't resolve to a valid integer constant expression:

_DEBUG;%(PreprocessorDefinitions)

Anything in the Visual Studio Preprocessor Definitions options gets translated to the /D command line option for cl.exe. So as an example,

If you set Visual Studio to diagnostic output then you can find something like:

1>    C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe /c /ZI /JMC /nologo /W3 /WX- /diagnostics:column /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /std:c++17 /permissive- /Fo"x64\Debug\\" /Fd"x64\Debug\vc143.pdb" /external:W3 /Gd /TP /FC /errorReport:prompt main.cpp
1>    Tracking command:
1>    C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i C:\Users\Darran\source\repos\test\test\x64\Debug\test.tlog /r C:\USERS\DARRAN\SOURCE\REPOS\TEST\TEST\MAIN.CPP /b MSBuildConsole_CancelEventd5692eb26b7f4d5b9b73d3d3e6845515  /c "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.44.35207\bin\HostX64\x64\CL.exe"  /c /ZI /JMC /nologo /W3 /WX- /diagnostics:column /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /std:c++17 /permissive- /Fo"x64\Debug\\" /Fd"x64\Debug\vc143.pdb" /external:W3 /Gd /TP /FC /errorReport:prompt main.cpp
1>    main.cpp

in the output. If you look in the build intermediate directory, you can also find the <projectname>.tlog directory. This has the CL.command.1.tlog (the 1 should be its position in the build order). This contains the options given to the compiler on the command line. This contains something like:

^C:\USERS\DARRAN\SOURCE\REPOS\TEST\TEST\MAIN.CPP
/c /ZI /JMC /nologo /W3 /WX- /diagnostics:column /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /std:c++17 /permissive- /Fo"X64\DEBUG\\" /Fd"X64\DEBUG\VC143.PDB" /external:W3 /Gd /TP /FC C:\USERS\DARRAN\SOURCE\REPOS\TEST\TEST\MAIN.CPP

The reason why I mention this is because of the documentation for the /D option.

"By default, the value associated with a symbol is 1. For example, /D name is equivalent to /D name=1. In the example at the end of this article, the definition of TEST is shown to print 1."

If you have code such as:

#include <cstdio>

int wmain()
{
	wprintf(L"%d\n", _DEBUG);

	return 0;
}

1 is indeed written to the console, so the preprocessor symbols have a valid integer value in your case.

Have you modified any preprocessor definitions? I have not had any problems building using this version of C++/WinRT with the compiler set to C++20. Yes, I am also aware that the abover command lines show /std:c++17, they were only to show that preprocessor directives are translated to /D.

[shelllet]

@DarranRowe, thank you! Your explanation is very clear.

My project use the boost-python, and i found the file ..\boost\install\include\boost-1_87\boost\python\detail\wrap_python.hpp in line 209 redefine the macro _DEBUG

when i put mouse over _DEBUG macro , the tooltip does't display _DEBUG=1 (the code is modifed and use defined(_DEBUG) )

when i create new winui3 project with windowsappsdk 1.7.3 and put mouse over _DEBUG macro, tooltip display _DEBUG=1

My project build comandline is this:

to solve this problem, i prefer to use #elif defined(_DEBUG) in line 203.

[DarranRowe]

As I previously wrote, the CppWinRT repository is here.

The Windows App SDK uses CppWinRT to generate the projection, and base.h is part of that. To demonstrate this, I set up a little command line environment. I download the CppWinRT package from NuGet, extract it (since it is a renamed .zip file) to a directory named cppwinrt.

The executable, cppwinrt.exe, can be found easily inside this directory.

I am using this since it is the version that the WinUI 3 project templates use. Anyway, if I use this to generate a projection for just the Windows Union metadata, no Windows App SDK at all, then base.h is still generated.

But I will also say that boost-python undefining and redefining preprocessor constants in a method not compatible with the original definition is a major problem too.