This is an archive of the discontinued LLVM Phabricator instance.

Adjust msvc_stdlib_force_include.hpp to handle clang++
ClosedPublic

Authored by EricWF on Jan 19 2017, 1:52 PM.

Details

Diff Detail

Event Timeline

EricWF updated this revision to Diff 85025.Jan 19 2017, 1:52 PM
EricWF created this revision.

Upload correct diff.

STL_MSFT requested changes to this revision.Jan 19 2017, 2:23 PM
STL_MSFT added inline comments.
test/support/msvc_stdlib_force_include.hpp
14

Is this comment accurate anymore - i.e. are you using it for Clang with MSVC's STL with libc++'s tests? (Note: we'll probably be interested in doing that in the future too, with Clang/C2 - I just haven't done so because it would double our testing time.)

If so, should it be reworded to drop "compiler and"?

24

Silly question, does stdlib.h define _LIBCPP_VERSION for you? I thought you didn't control your CRT.

56

Stylistically, I usually recommend !defined(clang) here, since that's what you tested.

64

We need TEST_STD_VER from somewhere - I preferred to define it here instead of in our test harness. (The idea was that this header would be our central source of macros.) Do you really need to remove it from this file? If so, I can live with that, I just want to make sure.

Note that MSVC's STL has a mostly-C++14 mode (all of C++14 plus the parts of C++17 we had implemented as of 2015 Update 2) and a partially-C++17 mode (enabled by /std:c++latest). While we test both modes in our internal tests, with libc++'s tests I've just used the C++17 mode so far (it is generally a superset, except for the removed features, and we have to enable those anyways for you).

I suppose there's another way to do this. After including any MSVC STL header, _HAS_CXX17 is defined to either 0 or 1, telling you what mode we're in. Good old <ciso646> provides this.

This revision now requires changes to proceed.Jan 19 2017, 2:23 PM
EricWF marked an inline comment as done.Jan 19 2017, 2:28 PM
EricWF added inline comments.
test/support/msvc_stdlib_force_include.hpp
24

Yes stdlib.h and most other C headers define _LIBCPP_VERSION. We con't control our CRT but we do wrap the headers in our own versions that adjust according to the C++ library spec as needed. (PS. This is why libc++ needs #include_next)

64

I don't have to remove it, no. but shouldn't test_macros.h default TEST_STD_VER to 16 by default, or does MSVC still emit __cplusplus == 201403L? I know when targeting your STL with clang++ -std=c++1z this was unneeded, I assumed the same for MSVC.

EricWF updated this revision to Diff 85036.Jan 19 2017, 2:29 PM
EricWF edited edge metadata.
  • Fix incorrect comment at top of file.
  • Fix non-matching #endif comment.
STL_MSFT requested changes to this revision.Jan 19 2017, 2:41 PM
STL_MSFT added inline comments.
test/support/msvc_stdlib_force_include.hpp
64

C1XX says __cplusplus == 199711 (even VS 2017 with /std:c++latest). Basically, we can't rev that number until we've implemented everything in C++11 (including two-phase, C99 preprocessor, and Expression SFINAE), or the Internet would riot ("how DARE you claim conformance you don't have", torches and pitchforks, etc.).

C1XX indicates /std:c++14 versus /std:c++latest with _MSVC_LANG (which is basically what __cplusplus would be), while the STL indicates its level of support with _HAS_CXX17 (because we support compiler-latest with STL-14).

How about this for a fix: (1) have this header stop defining TEST_STD_VER, (2) teach test_macros.h to see whether _HAS_CXX17 is defined before inspecting __cplusplus (and test_macros.h already includes <ciso646>), and (3) if _HAS_CXX17 is defined to 1, define TEST_STD_VER to 17 (it's the current year!), (4) if _HAS_CXX17 is defined to 0, define TEST_STD_VER to 14 (close enough, our extra Update 2 features shouldn't interfere).

This revision now requires changes to proceed.Jan 19 2017, 2:41 PM
EricWF updated this revision to Diff 85048.Jan 19 2017, 3:25 PM
EricWF edited edge metadata.

Re-add #define TEST_STD_VER 17

STL_MSFT accepted this revision.Jan 19 2017, 3:46 PM
This revision is now accepted and ready to land.Jan 19 2017, 3:46 PM
EricWF closed this revision.Jan 19 2017, 3:59 PM