Transition away from OS-33790456

[davidmrdavid]

Re-creation of: #5660

As reported in devcomm 1126857, several UCRT functions are declared as static inline, especially those in time.h.

This non-conforming signature prevents us from naively exporting those functions via modules. We have workarounds for this, but they're imperfect.

Thankfully, the October 2025 Windows SDK release (v10.0.26100.6901) improves on this issue.
It exposes a new binary macro _STATIC_INLINE_UCRT_FUNCTIONS . When set to 0, the functions will have 'external linkage' (conforming behavior, compatible with modules) and when set to 1, the functions will have static linkage for backwards compatibility.

For MSC_VER_ >= 1950, _STATIC_INLINE_UCRT_FUNCTIONS will default to 0. Otherwise, it'll default to 1.

This PR consumes the new macro and uses its value to determine whether or not to use our workarounds when building the std module.

Testing

I sense it's probably not worth it to add an automated test for this, but I'm open to be shown otherwise.

I have performed 2 local tests

(1)
In the STL repo, I manually added to the tests\std\tests\modules_20_matrix.lst the following diff:

diff --git a/tests/std/tests/modules_20_matrix.lst b/tests/std/tests/modules_20_matrix.lst
index 6ccb872f..d3d42a19 100644
--- a/tests/std/tests/modules_20_matrix.lst
+++ b/tests/std/tests/modules_20_matrix.lst
@@ -16,5 +16,8 @@ RUNALL_CROSSLIST
 *      PM_CL="/MDd /GR- /D_HAS_STATIC_RTTI=0"
 *      PM_CL="/MDd /utf-8"
 RUNALL_CROSSLIST
+*      PM_CL="/D_STATIC_INLINE_UCRT_FUNCTIONS=0"^M
+*      PM_CL="/D_STATIC_INLINE_UCRT_FUNCTIONS=1"^M
+RUNALL_CROSSLIST^M
 PM_CL=""
 ASAN   PM_CL="-fsanitize=address /Zi" PM_LINK="/debug"

Then I ran: python tests\utils\stl-lit\stl-lit.py ..\..\tests\std\tests\P2465R3_standard_library_modules

To my knowledge, that allows me to test all modules tests with the UCRT macro toggled on and off. In both cases, there's no regressions in STL functionality.

(2)

In an x64 native tools shell with the October '25 WIndows SDK installed, I tried manually exporting the affected UCRT functions in a module, like so:

C:\Users\dajusto\source\repros\ucrtscratch>type my_module.ixx
module;

// needed to access external linkage CRT functions before MSVC_VER 1950 is released.
#define _STATIC_INLINE_UCRT_FUNCTIONS 0

#include <corecrt_memcpy_s.h>
#include <corecrt_wstring.h>
#include <corecrt_wtime.h>
#include <string.h>
#include <sys/stat.h>
#include <sys/timeb.h>
#include <sys/utime.h>
#include <time.h>

#include <vector>

export module time_module;

export using ::wcsnlen_s;
export using ::_wctime;
export using ::_wctime_s;
export using ::strnlen_s;
export using ::fstat;
export using ::stat;
export using ::ftime;
export using ::_utime;
export using ::_futime;
export using ::_wutime;
export using ::utime;
export using ::ctime;
export using ::difftime;
export using ::gmtime;
export using ::localtime;
export using ::_mkgmtime;
export using ::mktime;
export using ::time;
export using ::timespec_get;
export using ::ctime_s;
export using ::gmtime_s;
export using ::localtime_s;
C:\Users\dajusto\source\repros\ucrtscratch>cl /std:c++20 /c my_module.ixx /EHsc
Microsoft (R) C/C++ Optimizing Compiler Version 19.44.35217 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

my_module.ixx

C:\Users\dajusto\source\repros\ucrtscratch>

As you can see, that worked.

This gives me confidence in the change. But again, I'm open to automated testing. Thanks!

[davidmrdavid]

Sorry for the force push: I messed up some of the commit text when incorporating feedback through the GitHub UI.

[StephanTLavavej]

I recommend never using the GitHub UI to make changes; they should always be built and tested locally. (I got burned too many times by introducing validation errors, etc.)

Technically I don't care how one makes changes as long as the results are good, but this is my advice to get things right the first time.

[DanielaE]

@davidmrdavid I have tested your changes with my foundational ms.URCT module plus a chain of dependent ones like std, Windows, Qt, and Boost, up to some of our in-house apps that themselves depend on the mentioned modules.

As you announced, I need to retain the workaround for _wcstok(), but the rest of my list in #5660 can be switched off now with the new UCRT.

Despite this sad (and somewhat inconsequential) annoyance, every tested application builds and works, without reaching out to headers from the mentioned libraries. Thanks!

[davidmrdavid]

Thanks @DanielaE for the manual test! That's a useful datapoint for us.

Agreed that it's unfortunate that a few leftovers remain, such as _wcstok(). It's on my radar to deal with those eventually, they just need more work to avoid strange linker errors.