This improves readability and (theoretically) improves portability,
as _Ugly names are reserved.
This performs additional de-uglification, so all of these tests
follow the example of iterator.traits/empty.pass.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@310761 91177308-0d34-0410-b5e6-96231b3b80d8
libc++'s inline namespace can change depending on the ABI version.
Instead of hardcoding __1 in the manual Microsoft ABI manglings for the
iostream globals, stringify _LIBCPP_NAMESPACE and use that instead, to
work across all ABI versions.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@310290 91177308-0d34-0410-b5e6-96231b3b80d8
This function template is referenced inside class basic_string as a
friend function. The extern template declaration needs to be above that
friend declaration to actually take effect.
This is important because this function was marked as exported in
r307966, so without the extern template taking effect, it can leak into
other DSOs as a visible symbol.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@309474 91177308-0d34-0410-b5e6-96231b3b80d8
This makes them consistent (many comments already used uppercase).
The special REQUIRES, UNSUPPORTED, and XFAIL comments are excluded from this change.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@309468 91177308-0d34-0410-b5e6-96231b3b80d8
Creating a function pointer with proper parameters pointing to std::next() or std::prev() should work.
This change moves the invented paramater for enable_if over to the return type to resolve this QoI issue.
Patch by Jason Liu.
Differential Revision: https://reviews.llvm.org/D34649
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@308932 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC's STL is replacing _HAS_FUNCTION_ASSIGN with _HAS_FUNCTION_ALLOCATOR_SUPPORT,
and is adding _HAS_UNEXPECTED.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@308535 91177308-0d34-0410-b5e6-96231b3b80d8
The set of #ifdefs used to handle the two incompatible variants of
strerror_r were not complete (they didn't handle newlib appropriately).
Rather than attempting to make the ifdefs more complex, make them
unnecessary by choosing which behavior to use dependent upon the
return type.
Reviewers: waltl
Differential Revision: https://reviews.llvm.org/D34294
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@308528 91177308-0d34-0410-b5e6-96231b3b80d8
Some targets (e.g. Darwin) might have the Win32 API available, but they
do not use MSVC CRT. Assume _LIBCPP_MSVCRT only when _MSC_VER is available
and __MINGW32__ isn't defined.
Differential Revision: https://reviews.llvm.org/D34588
rdar://problem/32628786
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@308225 91177308-0d34-0410-b5e6-96231b3b80d8
Once upon a time, extern templates used to be a Microsoft extension, so
cl would warn about their usage, and libc++ suppressed that warning.
They've long since been standardized, so the warning is defunct. (libc++
also doesn't currently support building with cl anyway.)
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307997 91177308-0d34-0410-b5e6-96231b3b80d8
It has an extern template instantiation declaration in the headers and a
corresponding instantiation definition in the library, so we must mark
it with _LIBCPP_FUNC_VIS to make it available outside the library.
This doesn't cause any ABI changes as-is since we don't build libc++
with hidden visibility (so the function is exported anyway). It's needed
for building libc++ with hidden visibility, however.
Clarify the Windows behavior for extern function templates while I'm
here, since this exercises that behavior.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307966 91177308-0d34-0410-b5e6-96231b3b80d8
It's supposed to be "class template" and "function template" instead of
"template class" and "template function".
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307954 91177308-0d34-0410-b5e6-96231b3b80d8
When using LIBCXX_ABI_UNSTABLE=YES, clang-cl gave the following warning:
P:\llvm_master\src\llvm\projects\libcxx\include\string(683,51):
warning: enumerator value is not representable in the underlying type
'int' [-Wmicrosoft-enum-value]
Fixed by switching from enums to static const size_type.
https://reviews.llvm.org/D35174
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307751 91177308-0d34-0410-b5e6-96231b3b80d8
The libc++ <__refstring> headers has no real reason why it should
be a public header that libc++ ships. The only reason it was in the include
directory was because libc++abi needed it to build the library.
However keeping <__refstring> a header had other problems, like requiring its
dependancies to also be in the headers. For that reason this patch
moves it into the source directory.
To work around libc++abi's need for this header a duplicated copy was added
to libc++abi in r307748. While duplicating the code is an unfortunate solution
it's the best solution that's currently possible.
In the future I would like to start a discussion on the mailing lists about
making libc++abi build as a sub-project of libc++, requiring the libc++ sources
always be present.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307749 91177308-0d34-0410-b5e6-96231b3b80d8
