MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can
also define _MSC_VER, and MSVCRT is not necessarily the only C runtime,
these macros should not be used interchangeably.
This patch divides all Windows-related bits into the aforementioned
categories. Two new macros are introduced:
- _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using
_MSC_VER, excluding Clang.
- _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default
when _WIN32 is defined.
This leaves _WIN32 for code using the Windows API.
This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF.
Nico, please prepare a patch for CREDITS.TXT, thanks.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@187593 91177308-0d34-0410-b5e6-96231b3b80d8
inlined. These do not need to be always-inlined for ABI stability because they are not exported beyond this source due to the unnamed namespace.
Also simplified use of the Wmissing-field-initializers pragma as was done for clang.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@171202 91177308-0d34-0410-b5e6-96231b3b80d8
__time_get_storage<char> to match the initialization behavior in
__time_get_storage<wchar>. Without the initialization, valgrind
reports errors in the subsequent calls to strftime_l.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@161196 91177308-0d34-0410-b5e6-96231b3b80d8
localization/locale.categories/category.collate/category.ctype/locale.ctype.byname/is_1.pass.cpp
and scan_is.pass.cpp. The tests fail when the character class being
tested is compound, like ctype_base::alnum or ctype_base::graph,
because the existing series of conditionals in do_is an do_scan_is
will abort too early. For instance, if the character class being
tested is alnum, and the character is numeric, do_is will return false
because iswalpha_l will return false, 'result' becomes false, and the
'true' result from the later call to iswdigit_l ends up being ignored
. A similar problem exists in do_scan_is.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@161192 91177308-0d34-0410-b5e6-96231b3b80d8
Solaris not providing some of the locales that the test suite uses.
Note: This depends on an xlocale (partial) implementation for Solaris and a
couple of fixed standard headers. These will be committed to a branch later
today.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@151720 91177308-0d34-0410-b5e6-96231b3b80d8
libc++ now mostly works on FreeBSD with libcxxrt and this patch applied to the base system:
http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110920/e666632c/xlocale-0001.obj
Summary of tests on FreeBSD:
****************************************************
Results for /root/libcxx/test:
using FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: x86_64-unknown-freebsd9.0
Thread model: posix
with -std=c++0x -stdlib=libc++ -I/root/libcxx/include -L/root/libcxx/build/lib
----------------------------------------------------
sections without tests : 1
sections with failures : 48
sections without failures: 1015
+ ----
total number of sections : 1064
----------------------------------------------------
number of tests failed : 145
number of tests passed : 4179
+ ----
total number of tests : 4324
****************************************************
(Many due to this clang version not supporting C++ atomics)
More fixes to follow...
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@140245 91177308-0d34-0410-b5e6-96231b3b80d8
all platforms. Unfortunately a lot of this remains conditionally
compiled so as not to break Apple's ABI.
The new _LIBCPP_LOCALE__L_EXTENSIONS macro can be defined on other
platforms that support _l suffixes for all functions in order to use
them.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@135035 91177308-0d34-0410-b5e6-96231b3b80d8
traits.
To the best of my knowledge, this will not break the ABI for Apple.
However, it does introduce three publicly visible (although with
reserved name) functions that will fail to link against the just-shipped
Apple version of libc++. Since they are not used in any inline
functions, no actual breakage should occur.
If Howard doesn't want to put undefined functions (even internal ones)
into a header, they could be surrounded by additional conditional
compilation.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@134781 91177308-0d34-0410-b5e6-96231b3b80d8
