STL: Non-standard non-reserved identifiers available via standard headers

[frederick-vs-ja]

Describe the bug
The C++ standard allows user-defined macros to have non-reserved names. However, MSVC STL introduces some non-standard non-reserved via standard headers, which makes user-defined macros with such names able to paralyze the MSVC STL implementation.

The list of names may be incomplete:

• stdext related:
  • <xhash>, <iterator> (also used in <yvals_core.h>): stdext
  • <unordered_map>, <unordered_set> (ultimately, <xhash>): hash_compare
  • <iterator>: checked_array_iterator, unchecked_array_iterator, make_checked_array_iterator, make_unchecked_array_iterator (related: <iterator>: Consider deprecating and removing stdext::checked_array_iterator/unchecked_array_iterator #951)
• TR1 related (<random>: Remove TR1 machinery #183, <random>: Still provides the uniform_int and uniform_real class templates #1002):
  • <random>: linear_congruential, subtract_with_carry, mersenne_twister, discard_block, uniform_int, uniform_real
• Miscellaneous
  • <typeinfo> (ultimately, <vcruntime_typeinfo.h>): raw_name (<typeinfo>: non-Standard extension type_info::raw_name #2195)
  • <chrono> (ultimately, <xtimec.h>): xtime_get, xtime, sec, nsec (related: <xtimec.h>: Stop exporting internal-only functions #274) this is fixed except for the symbol name xtime_get

May be all of them shoud be either removed or have their names changed to reseved identifiers in vNext.

The namespace tr1 and some non-standard names inside it are not counted as they are guarded by _HAS_TR1_NAMESPACE. Can we handle some stdext components like tr1 before vNext arrives?

Command-line test case

C:\Temp>type repro.cpp
#define raw_name                      delete // <vcruntime_typeinfo.h>, via <typeinfo>

#define xtime_get                     delete // <xtimec.h>, via <chrono>, <xthreads.h>, <thread>, <mutex>, <condition_variable>
#define xtime                         delete // same as above
#define sec                           delete // same as above
#define nsec                          delete // same as above

#define stdext                        delete // <xhash>, <yvals_core.h>, via <iterator>

#define hash_compare                  delete // <xhash>, via <unordered_map>, <unordered_set>

#define checked_array_iterator        delete // <iterator>
#define unchecked_array_iterator      delete // <iterator>
#define make_checked_array_iterator   delete // <iterator>
#define make_unchecked_array_iterator delete // <iterator>

#define linear_congruential           delete // <random>
#define subtract_with_carry           delete // same as above
#define mersenne_twister              delete // same as above
#define discard_block                 delete // same as above
#define uniform_int                   delete // same as above
#define uniform_real                  delete // same as above

#include <typeinfo>
#include <chrono>
#include <unordered_map>
#include <random>
#include <iterator>

int main()
{
}

C:\Temp>cl /EHsc /W4 /WX /std:c++17 .\repro.cpp
用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.29.30133 版
版权所有(C) Microsoft Corporation。保留所有权利。

repro.cpp
(omitted for short)
C1003: 错误计数超过 100；正在停止编译

Expected behavior
This program should compile.

STL version
Microsoft Visual Studio Community 2019
版本 16.11.2

Additional context
The MS CRT also provides some non-standard non-reserved names (e.g. fread_s). I don't know whether such issue has been reported or how to report it.

[frederick-vs-ja]

<future> includes <ppltasks.h> and thus drags a bunch of (more than 60) non-Standard non-reserved identifiers in.

[StephanTLavavej]

As an aside, the Standard Library Modules are the first way to avoid this problem.

[frederick-vs-ja]

🙀<arm64_neon.h> (usage added in #2127) is extremely problematic. It drags in thousands of pretty names.

Edit: this is resolved by #4695!