llvm-svn: 192142

llvm-svn: 192085

Apparently, I don't know the difference between 'left' and 'right'. Swap parameters named 'lhs' and 'rhs' so that they correctly refer to the 'left hand side' and 'right hand side' of comparisons. No functionality change. Thanks to Arthur O'Dwyer for pointing this out to me.

llvm-svn: 192080

Rather than try to protect the function behind a precise,
ever-changing #if expression, just inline it into every caller.

llvm-svn: 192077

libsupc++ does not implement the dependent EH ABI and the
functionality it uses to implement std::exception_ptr (which it
declares as an alias of std::__exception_ptr::exception_ptr) is not
directly exported to clients. So we have little choice but to hijack
std::__exception_ptr::exception_ptr's (which fortunately has the
same layout as our std::exception_ptr) copy constructor, assignment
operator and destructor (which are part of its stable ABI), and its
rethrow_exception(std::__exception_ptr::exception_ptr) function.

Also, remove some out of date comments.

Differential Revision: http://llvm-reviews.chandlerc.com/D1826

llvm-svn: 192076

Linking against libstdc++, rather than libsupc++, is probably better
for people who need to link against clients of libstdc++.  Because
libsupc++ is provided only as a static library, its globals are not
shared between the static library and the copy linked into libstdc++.
This has been found to cause at least one test failure.

This also removes a number of symbols which were multiply defined
between libstdc++ and libc++, only when linking with libstdc++.

Differential Revision: http://llvm-reviews.chandlerc.com/D1825

llvm-svn: 192075

The remaining multiple definitions were flushed out by attempting to
link libsupc++ and libc++ into the same executable with --whole-archive,
e.g.

clang++ -I../llvm/projects/libcxx/include -nodefaultlibs -Wl,--whole-archive lib/libc++.a /usr/lib/gcc/x86_64-linux-gnu/4.6/libsupc++.a -Wl,--no-whole-archive -lgcc -lgcc_s -lc -lpthread -lrt

(The same technique was used to flush out multiple definitions in
libstdc++.)

Differential Revision: http://llvm-reviews.chandlerc.com/D1824

llvm-svn: 192074

G M: 1. It changes the temp file handling to use the template and the current directory for windows, matching how it works on other platforms.
2. It re-enables the temp file handling for mingw that regressed.

llvm-svn: 192073

llvm-svn: 192072

llvm-svn: 192071

llvm-svn: 192068

llvm-svn: 192058

llvm-svn: 192057

Add tests making sure that optional<T>s can be compared at compile time; this functionality was enabled by N3789

llvm-svn: 192051

llvm-svn: 192049

llvm-svn: 192048

llvm-svn: 192047

llvm-svn: 192038

llvm-svn: 192012

 
I've changed it so we don't set highest level warnings (all) for MSVC when building projects using cmake and instead leave the default. That's /W4 on my machine and seems to be ok.
 
With all warnings on for msvc, we see literally thousands of warnings. 99.99% aren't relevant and just obscure the ones that are.
I think the user can still override things if they want something different from the command line when using cmake.

llvm-svn: 192010

G M: The attached patch is for libcxx's new.cpp and __config files. The patch's intent is to make new.cpp compile using MS's cl.exe compiler without changing the meaning of anything for any other compiler.

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.

llvm-svn: 192007

G M: A small patch to fix a couple of warnings in stdexcept.cpp for cl.exe which does not support #pragma visibility.

llvm-svn: 191988

G M: Changes all references to "x inline" to "inline x" where x = _libcpp_always_inline or _libcpp_inline_visibility macros.

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.

llvm-svn: 191987

G M: Fix libcxx's detection of rtti disablement for g++.exe and cl.exe. When RTTI is NOT enabled, _LIBCPP_NO_RTTI is defined.

llvm-svn: 191981

G M: Provides the _LIBCPP_WARNING macro, to be used for MSVC only, since that compiler doesn't support #warning.

llvm-svn: 191980

llvm-svn: 191935

libsupc++ declares these constructors inline, so we won't necessarily
get a definition for them in the library.

llvm-svn: 191931

llvm-svn: 191930

libcxx doesn't build with -Werror because of #warnings in its source
code. But when libcxx is built as an external LLVM project, it inherits
LLVM build flags, breaking the build if LLVM_ENABLE_WERROR is enabled.

llvm-svn: 191814

llvm-svn: 191756

Part 8 of LWG Issue 2210' unordered_set and unordered multiset; this got missed when I went on vacation

llvm-svn: 191705

SCARY/N2913 iterator support between the multi and non-multi versions of the associative and unordered containers.  I beleive lack of support for this was accidentally recently introduced (by me) and this is fixing a regression.  This time tests are put in to prevent such a regression in the future.

llvm-svn: 191692

Otherwise if libcxx is built as an LLVM external project (after r191624),
"include(config-ix)" will include config-ix.cmake from LLVM, not from libcxx,
which will result in misconfigured build tree.

llvm-svn: 191657

llvm-svn: 191626

llvm-svn: 191625

llvm-svn: 191598

llvm-svn: 191596

llvm-svn: 191575

llvm-svn: 191573

libsupc++ in typeinfo.cpp, bringing it into agreement with
exception.cpp. This fixes link errors due to duplicate symbols from
this translation unit.

llvm-svn: 191397