You can see how existing variable templates are defined, e.g. :

But since _Is_elem_cptr is a member, you should use static in place of _INLINE_VAR.

After making _Is_elem_cptr a variable template, you should also change all occurences of _Is_elem_cptr<something>::value to _Is_elem_cptr<something>.

You can see how existing variable templates are defined, e.g. :

STL/stl/inc/xtr1common

Lines 189 to 190 in b7e0365

	template <class _Ty>
	_INLINE_VAR constexpr bool is_floating_point_v = _Is_any_of_v<remove_cv_t<_Ty>, float, double, long double>;

But since _Is_elem_cptr is a member, you should use static in place of _INLINE_VAR.

After making _Is_elem_cptr a variable template, you should also change all occurences of _Is_elem_cptr<something>::value to _Is_elem_cptr<something>.

i think i fixed it in daddfb2
can you please take a look on what i did?

Great, and further improvement can be done.
Note that

You can (and should) link your pull request to this issue using GitHub's close/fix/resolve syntax.
(in the PR description not the commit message)

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

Unfortunately, while this change is correct, it triggers a /clr:pure compiler bug which is unlikely to ever be fixed:

test.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '???__E??$_Is_elem_cptr@PAD@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@$$Q0_NB@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@YMXXZ@?A0xbffd14b2@@$$FYMXXZ'

(Noticed only when mirroring to the MSVC-internal repo, as we haven't gotten around to porting the /clr:pure build to GitHub yet.)

Unfortunately, while this change is correct, it triggers a /clr:pure compiler bug which is unlikely to ever be fixed:

test.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '???__E??$_Is_elem_cptr@PAD@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@$$Q0_NB@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@YMXXZ@?A0xbffd14b2@@$$FYMXXZ'

(Noticed only when mirroring to the MSVC-internal repo, as we haven't gotten around to porting the /clr:pure build to GitHub yet.)

There's no solution to this compiler error?

while this change is correct, it triggers a /clr:pure compiler bug

According to the docs:

/clr:pure is deprecated. The option is removed in Visual Studio 2017 and later.

It was deprecated long time ago, so why even bother? 🥱

Unfortunately, while this change is correct, it triggers a /clr:pure compiler bug which is unlikely to ever be fixed:

test.obj : fatal error LNK1179: invalid or corrupt file: duplicate COMDAT '???__E??$_Is_elem_cptr@PAD@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@$$Q0_NB@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@YMXXZ@?A0xbffd14b2@@$$FYMXXZ'

(Noticed only when mirroring to the MSVC-internal repo, as we haven't gotten around to porting the /clr:pure build to GitHub yet.)

Urgh, Now it remember that I had that change in the ASAN string branch and pulled it out because of this failure :(

@YairBorn

There's no solution to this compiler error?

Unfortunately, there isn't - we aren't aware of any workarounds, and the compiler team hasn't found a way to fix this longstanding issue (which involves name mangling, and hence binary compatibility). 😿

While we can't merge this change, this code could instead be commented as to why we aren't using a static constexpr data member. Would you like to change your PR to do that? We mark issues that can be addressed in the (possibly far) future as "TRANSITION" (indicating a temporary state of affairs), followed by a short explanation. Here, // TRANSITION, /clr:pure is incompatible with templated static constexpr data members would be a reasonable explanation. (Note that we have a 120 column limit for code format validation.)

While we can't merge this change, this code could instead be commented as to why we aren't using a static constexpr data member. Would you like to change your PR to do that? We mark issues that can be addressed in the (possibly far) future as "TRANSITION" (indicating a temporary state of affairs), followed by a short explanation. Here, // TRANSITION, /clr:pure is incompatible with templated static constexpr data members would be a reasonable explanation. (Note that we have a 120 column limit for code format validation.)

If I get you right, you want me to undo all of my changes, and add the comment you mentioned?

If I get you right, you want me to undo all of my changes, and add the comment you mentioned?

Yep, that's correct.

If I get you right, you want me to undo all of my changes, and add the comment you mentioned?

Yep, that's correct.

Done in YairBorn@60ae0ff

If I get you right, you want me to undo all of my changes, and add the comment you mentioned?

Yep, that's correct.

Done in YairBorn@60ae0ff, but o don't know why the tests failed...

If I get you right, you want me to undo all of my changes, and add the comment you mentioned?

Yep, that's correct.

Done. all tests passed! 😸

Urgh, Now it remember that I had that change in the ASAN string branch and pulled it out because of this failure :(

I didn't remember, but I do recall thinking "Why haven't we done this before?" when filing the issue. Hopefully the comment will prevent us from wasting more people's time doing this again in the future.

I'm mirroring this to the MSVC-internal repo (again) - please notify me if any further changes are pushed.

Thanks for working on this change - twice - and documenting why the STL behaves like this. Also, congratulations on your first microsoft/STL commit! 🎉 😻 🚀

This change will ship in VS 2022 17.4 Preview 3.