Include instead of

[Stephan T. Lavavej (StephanTLavavej)]

• We no longer need
  

  STL/stl/inc/xatomic.h

  Lines 14 to 16 in 5f736ef

  	#if defined(_WIN64) && (_MSC_FULL_VER <= 192829213) // TRANSITION
  	#include <intrin.h> // Visual Studio 2019 to define 128-bit CAS in
  	#endif // defined(_WIN64) && (_MSC_FULL_VER <= 192829213), TRANSITION

  
  as VS 2019 16.8 Preview 5 contains this change, and its _MSC_FULL_VER exceeds this value. (Also, the MSVC-internal build always uses the latest .)
• In stl/inc, consistently include instead of . Previously, we had approximately 42 includes of and 26 of , so this reduces inconsistency. There should be essentially no throughput cost (especially because in many cases, was already being included through another path). There is also a slight user experience benefit to consistently using - while unrelated to any Standard guarantee, it is less surprising if we always drag in ::meow and std::meow simultaneously.
• This doesn't change any other product code - e.g. we still use _CSTD to access names.
• Change most C wrapper headers to be core headers.
  • These are now core: cassert, cctype, cerrno, cfenv, cinttypes, clocale, csetjmp, csignal, cstdarg, cstring, ctime, cuchar, cwctype.
  • We need to change xstoul.cpp and xstoull.cpp because they're now including only core C wrapper headers, yet they're using the DLL export macro. Therefore, they should directly include yvals.h.
• Test core headers. Resolves Test "core" headers #1411.
• doesn't need to include .
  • It doesn't mention anything that provides.
  • provides uses_allocator and allocator_arg.
• Small cleanups in xstol.cpp, xstoll.cpp, xstoul.cpp.
  • xstol.cpp doesn't need xmath.hpp, which is for floating-point.
  • xstoll.cpp doesn't need xmath.hpp either, but will need yvals.h.
  • xstoul.cpp had a leftover "macros" comment. Also, remove an empty line and move the "valid digits" comment to be more consistent with xstoull.cpp.

[Stephan T. Lavavej (StephanTLavavej)]

I will need to revise this - we've discovered that some headers are non-core when they should be core.

[Casey Carter (CaseyCarter)]

I will need to revise this - we've discovered that some headers are non-core when they should be core.

Clarifying the distinction: "core" headers don't require linking to the DLL(s) to function, so they don't include the pragma that directs the linker to link in msvcp (nor any other C++ DLL). We annotate them by adding (core) to the first-line comment in each such header. Core headers can include other core headers, but no non-core headers.

[Stephan T. Lavavej (StephanTLavavej)]

We also have a whole wiki page about them: https://github.com/microsoft/STL/wiki/The-Difference-Between-Core-And-Non-Core-Headers
I think I will add test coverage since this is clearly fragile.

[Casey Carter (CaseyCarter)]

Approved with suggestions.