------------------------------------------------------------------------
r197061 | marshall | 2013-12-11 11:32:32 -0800 (Wed, 11 Dec 2013) | 1 line
Move std::begin(array) and std::end(array) out from under an #ifdef that was preventing people from building libc++ using gcc. This corrects a mistake that I introduced in r196058
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@197134 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r196058 | marshall | 2013-12-01 19:24:33 -0800 (Sun, 01 Dec 2013) | 1 line
Fix for PRPR17934; based on a fix suggested by Peter Sommerlad
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@197133 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r196058 | marshall | 2013-12-01 19:24:33 -0800 (Sun, 01 Dec 2013) | 1 line
Fix for PRPR17934; based on a fix suggested by Peter Sommerlad
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@197013 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r196058 | marshall | 2013-12-01 19:24:33 -0800 (Sun, 01 Dec 2013) | 1 line
Fix for PRPR17934; based on a fix suggested by Peter Sommerlad
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@196077 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r195693 | joerg | 2013-11-25 14:44:20 -0800 (Mon, 25 Nov 2013) | 3 lines
Don't use T as template argument, it is part of the application
namespace.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@195733 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r195136 | marshall | 2013-11-19 10:05:03 -0800 (Tue, 19 Nov 2013) | 1 line
Patch by Bruce Mitchener. Change all references to EMSCRIPTEN to __EMSCRIPTEN__. If you're not using the PP symbol EMSCRIPTEN, then you should see no functionality change.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/branches/release_34@195622 91177308-0d34-0410-b5e6-96231b3b80d8
functions in src/support/win32/locale_win32.cpp and locale_win32.h,
calling upon vsnprintf for which there is a MingW correct alternative.
Note! __USE_MINGW_ANSI_STDIO is not modified in this patch. In order to
use the __mingw version it must be defined before including the MingW
headers.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@195044 91177308-0d34-0410-b5e6-96231b3b80d8
trivial in C++03, thus making it trivial in both C++03 and C++11.
This patch allows one to opt-in/out of this decision with a macro. You can
choose to have the pair copy constructor always be trivial, or always be
non-trivial. The flag controlling this is now _LIBCPP_TRIVIAL_PAIR_COPY_CTOR.
The client can define this flag to 1, and the pair copy constructor will be
trivial (when possible of course), or to 0, and the pair copy constructor will
be nontrivial.
Default settings for this flag are set in <__config> (as usual). With this
commit the default is _LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 for all platforms
except __APPLE__, which defaults to _LIBCPP_TRIVIAL_PAIR_COPY_CTOR=0.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@194742 91177308-0d34-0410-b5e6-96231b3b80d8
pair, and a couple of pair-like implementation detail types. The
C++98/03 and 11 standards all specify that the copy constructor of
pair<int, int> is trivial. However as libc++ tracked the draft C++11
standard over the years, this copy constructor became non-trivial, and
then just recently was corrected back to trivial for C++11.
Unfortunately (for libc++1) the Itanium ABI specifies different calling
conventions for trivial and non-trivial copy constructors. Therefore
currently the C++03 libc++ copy constructor for pair<int, int> is ABI
incompatible with the C++11 libc++ copy constructor for pair<int, int>.
This is Bad(tm). This patch corrects the situation by making this copy
constructor trivial in C++03 mode as well.
Just in case it is needed for an incomplete C++11 compiler, libc++
retains the ability to support pair with rvalue references, but without
defaulted special members. However the pair needs non-trivial special
members to implement this special case, (as it did when clang was in
this place a couple of years ago).
During this work a bug was also found and fixed in
is_trivially_constructible.
And there is a minor drive-by fix in <__config> regarding
__type_visibility__.
A test is updated to ensure that the copy constructor of pair<int, int>
is trivial in both C++03 and C++11. This test will necessarily fail for
a compiler that implements rvalue references but not defaulted special
members.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@194536 91177308-0d34-0410-b5e6-96231b3b80d8
The issue this patch seeks to address is that MS's compiler (cl.exe) doesn't support the __attribute__((__weak__)) or __atribute__((__visibility__("default")) syntax; so a solution must be found where cl.exe doesn't see this syntax.
This patch seeks to solve this problem by changing code patterned like this:
__attribute__((__weak__, __visibility__("default")))
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { /*snip*/; return p; }
to code like this:
_LIBCPP_WEAK
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { return p; }
Howard: Thanks for all the comments regarding the default visibility
tag on the definition. I agree it isn't needed, and that there are lots
of other places where it is missing. That being said, I'm not wanting
to rock the boat on that issue right now. So I've added it back to the
definition via _LIBCPP_FUNC_VIS. A later pass dedicated just to this
issue can bring things in to a consistent state one way or the other.
Note that we do not want to have the exact same attributes on the
declaration and defintion in this case. The declaration should not be
marked weak, whereas the definition should (which is what G M's patch
did). I've fully tested on OS X to ensure that the resultant attribute
syntax actually works.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@192007 91177308-0d34-0410-b5e6-96231b3b80d8
The patch touches these files:
locale
array
deque
new
string
utility
vector
__bit_reference
__split_buffer
locale_win32.h
There is no intended functionality change and it is expected that reversing the position of the inline keyword with regard to the other keywords does not change the meaning of anything, least not for apple/Linux etc.
It is intended to make libcxx more consistent with itself and to prevent the 1000 or so
"inline.cpp(3) : warning C4141: 'inline' : used more than once" warnings that MS's cl.exe compiler emits without this patch, i.e. if inline is not the first keyword before a function name etc.
Prefer "inline [other inline related keyword]" over "[other related keyword] inline".
After this patch, libcxx should be consistent to this pattern.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@191987 91177308-0d34-0410-b5e6-96231b3b80d8
