__LINE__ 不是 MSVC 中的 constexpr

Question

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__;
}

But. Seemingly the same compiler on Godbolt compiles this ok. As ever before.

https://godbolt.org/z/rn44rN

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)) 

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?

Answer 1

Apparently, this is already a known issue by the MSVC community:

We have a known bug for this issue on the C++ team here. The status on this Developer Community item will be updated as that bug is looked at. Thanks again for reporting this to us.

Apparently, it is considered a "feature" of the compiler:

The bug is considered a feature: Edit-and-Continue has a small but vocal and enthusiastic group of users (mostly game developers)

A user in the linked thread offers the following as a workaround:

 #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

Answer 2

The MSVC team points out in that link that if you change the "Debug Information Format" from "/ZI" (Program Database for Edit and Continue) to "/Zi" (Program Database) this also fixes it (but disables edit and continue). It worked for me.

If you're not using Edit and Continue this seems like the right fix.