header-units.json: Comment out version, yvals.h, yvals_core.h

[StephanTLavavej]

Reported by @olgaark and confirmed by @cdacamar.

Header units are perfectly capable of emitting macros. However, the IDE's build system can be configured to perform "dependency scanning" when translating #include to import. During this scanning phase, the compiler and build system are effectively assuming that anything named in header-units.json won't emit macros that control the inclusion of other headers. (This is because we haven't built the header units yet - we're scanning dependencies to determine what header units to build in what order - and we're trying to avoid preprocessor-expanding anything named in header-units.json as that would defeat the purpose.)

This means that yvals.h and yvals_core.h shouldn't be marked as eligible for automatic translation of #include to import in header-units.json, because every STL header starts by including one of these two, and expects that they'll define macros that control whether other headers should be included. (Beginning with _STL_COMPILER_PREPROCESSOR guarding everything, also _HAS_CXX17/_HAS_CXX20 and the Standard feature-test macros.) (Note that _HAS_CXX17/_HAS_CXX20 are defined by vcruntime.h included by yvals_core.h.)

Finally, while the Standard specifies that <version> is importable, and this is indeed the case (import <version>; works just fine), we should also comment it out in header-units.json. While we never include <version> ourselves, its only purpose in life is to provide Standard feature-test macros, so users relying on dependency scanning and automatic translation of #include to import would run into the same problem if they #include <version> and then guard other includes with feature-test macros.

(If users are including other Standard headers to get feature-test macros to control the inclusion of other headers, it seems unavoidable that they'll have problems with dependency scanning and automatic translation - but using <version> is a superior strategy to begin with.)

[CaseyCarter]

(If users are including other Standard headers to get feature-test macros to control the inclusion of other headers, it seems unavoidable that they'll have problems with dependency scanning and automatic translation - but using <version> is a superior strategy to begin with.)

This suggests to me that none of the headers should be in header-units.json, and that having any is favoring throughput over correctness. Am I misunderstanding?

[StephanTLavavej]

You're technically correct - the best kind of correct. The compiler team is looking into ways to improve dependency scanning.

[MahmoudGSaleh]

LGTM