ok, the latest VS 2019 Community, local "all defaults" C++ console project:
int main()
{
// cl Version 19.21.27702.2 for x86
//
constexpr auto MSCVER = _MSC_VER; // 1921
constexpr auto MSCFULLVER = _MSC_FULL_VER; //192127702
constexpr auto MSCBUILD = _MSC_BUILD; // 2
/*
: error C2131: expression did not evaluate to a constant
: message : failure was caused by non-constant arguments or reference to a non-constant symbol
: message : see usage of '__LINE__Var'
*/
constexpr auto LINE = __LINE__;
}
Run Code Online (Sandbox Code Playgroud)
But. Seemingly the same compiler on Godbolt compiles this ok. As ever before.
Any idea?
The Status as of 2019-07-22
Apparently, this is a bug which is a feature. Ugh. And there is a macro which is almost perfect, besides the fact it casts to int, and the type of the LINE is long. Here is my version:
#define _DBJ_CONCATENATE_(a, b) a ## b
#define _DBJ_CONCATENATE(a, b) _DBJ_CONCATENATE_(a, b)
#define CONSTEXPR_LINE long(_DBJ_CONCATENATE(__LINE__,U))
Run Code Online (Sandbox Code Playgroud)
Original is here. I had almost the same solution, but I was adding a zero instead of U. Perhaps because I spent hours trying to figure out what is going on.
I am sorry, but the reasoning of the MSVC team on that page is just strange. I am wondering is there a detail in the standard which resolves this issue.
Many thanks to commenters for pointing me in the right direction. But there is this remaining mistery: How come Godbolt + MSVC, has no problems with this same code?
MSVC 团队在该链接中指出,如果将“调试信息格式”从“/ZI”(用于编辑并继续的程序数据库)更改为“/Zi”(程序数据库),这也会修复该问题(但会禁用编辑并继续) )。这对我有用。
如果您不使用“编辑并继续”,这似乎是正确的解决方案。
小智 5
显然,这已经是MSVC 社区的一个已知问题:
我们的 C++ 团队在此问题上有一个已知错误。该开发者社区项目的状态将在检查该错误时更新。再次感谢您向我们报告此事。
显然,它被认为是编译器的“功能”:
该错误被认为是一个功能:“编辑并继续”拥有一小部分但直言不讳且热情的用户群体(主要是游戏开发者)
链接线程中的用户提供了以下解决方法:
Run Code Online (Sandbox Code Playgroud)#define CAT(X,Y) CAT2(X,Y) #define CAT2(X,Y) X##Y #define USABLE_LINE int(CAT(__LINE__,U)) //appending 'U' shouldn't change much as __LINE__ is supposedly non-negative anyway