Fix import std;
interaction with <intrin.h>
emitting bogus error C2733
#4626
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes DevCom-10643328 VSO-2045649 "VS17.10-preview4 C++ Modules
import std;
fails to compile ifboost::unordered::unordered_hash_map
member of type also imported" which emitted:The root cause was that the STL drags in
<intrin.h>
(in whole or in part), and it defines a few types outside ofextern "C"
orextern "C++"
. This causes them to be attached to thestd
module, which we don't want. (I missed this in #4154.) The fix is to include<intrin.h>
in the Global Module Fragment.<intrin.h>
. In contrast, building the Standard Library Module is a one-time cost, so the simplest and safest thing to do is to include the whole<intrin.h>
here.extern "C"
. In fact, including them in the Global Module Fragment is basically redundant, although @cdacamar advised me that it was a good idea.<thread>
includes<process.h>
for_beginthreadex()
(this include is necessary) and<xiosbase>
includes<share.h>
for_SH_DENYNO
(this include is redundant; the UCRT's structure guarantees that we'd drag this in already). I considered adding these to the Global Module Fragment, but I thought that it was fine to rely on theirextern "C"
nature.extern "C"
orextern "C++"
, and VCRuntime directly exports certain things now).<intrin.h>
family is large, ever-growing, and not entirely under our control (it's regularly enhanced by our processor partners). Changing it to wrap things inextern "C++"
could bit-rot over time. Putting it in the Global Module Fragment is simple, robust, and non-intrusive. (Also, it is strictly layered - it doesn't ever include STL machinery.<ppltasks.h>
had to be modified because it includes STL headers, so we couldn't put it in the GMF.)During this audit, I noticed that
<exception>
was including<malloc.h>
for absolutely no reason - I checked every single identifier and none are being used. Our "include each header alone" test is also happy with removal. I thought it was reasonable to include a one-line cleanup in this fix.Thanks to @Klaim and @boris-kolpackov for reporting this, and to @cdacamar for investigating.