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

llvm-svn: 191148

iterator, allocator) constructor with the intention of it being
implicitly converted to the allocator type, it is possible for overload
resolution to favour the (iterator, iterator, enable_if) constructor.
Eliminate this possibility by moving the enable_if to one of the
existing arguments and removing the third argument.

llvm-svn: 191145

Apply LWG 2048.  It is amazing to me that this actually works, but the existing tests confirm that it does.  c++1y status page now showing libc++ is complete for c++1y modulo dynarray issues.

llvm-svn: 191142

llvm-svn: 191141

llvm-svn: 191140

llvm-svn: 191127

llvm-svn: 191126

llvm-svn: 190857

llvm-svn: 190837

Marshall Clow:  LWG Issue 2056: future_errc enums start with value 0 (invalid value for broken_promise).

llvm-svn: 190756

llvm-svn: 190736