Module STD : Can't use crtdbg header

[Cazayus]

Describe the bug

It is currently impossible to use the crtdbg header with the std module
crtdbg.h is not a STL header, so it should not be affected by the current limitation of mixing import std and includes.

Command-line test case

C:\Temp>type repro.cpp
import std;
#include <crtdbg.h>

C:\Temp>cl.exe /std:c++latest /EHsc /nologo /c .\repro.cpp

C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.40.33807\include\vcruntime_new.h(27): error C2011: 'std::align_val_t': 'unsigned enum' type redefinition
C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.40.33807\include\vcruntime_new.h(27): note: see declaration of 'std::align_val_t'

Expected behavior

It should compile but does not

STL version

    Microsoft Visual Studio Community 2022
    Version 17.10.0 Preview 7.0

Additional context

This bug looks similar on the surface (but is probably unrelated) to the mixing of std module and <intrin.h> (which has been fixed but not yet made available in previews of Visual Studio)

[StephanTLavavej]

crtdbg.h is not a STL header, so it should not be affected by the current limitation of mixing import std and includes.

Unfortunately it is, because it's dragging in VCRuntime and its definition of std::align_val_t.

There were a couple of relevant PRs in this area - #4375 in VS 2022 17.10 Preview 3 made coordinated changes to the STL and VCRuntime so that VCRuntime entities are exported during their first declaration. Later, #4576 (which will ship in VS 2022 17.11 Preview 2) removed workarounds that were deactivated by the previous fix.

However, getting VCRuntime to export its own machinery doesn't solve the import-before-include scenario, which is affected by the same implementation limitation that prevents import std; before #include <vector> from working.

I'll keep this bug active for the time being. Until the implementation is overhauled, you'll need to ensure that you #include <crtdbg.h> before import std; - that scenario should work now that I've applied extern "C" and extern "C++" consistently.