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.

llvm-svn: 195044

Move <optional> into include/experimental, and into the std::experimental namespace, since it's not part of C++14, but of an upcoming TS

llvm-svn: 194867

llvm-svn: 194432

Patch from GM: locale.cpp; make implicit conversions to bool explicit, fix some 'unknown pragma' warnings when compiling under MSVC, and don't use the __sso_allocator under windows, b/c MSVC doesn't support aligned-by value parameters

llvm-svn: 193086

Patch from GM to make more implicit bools explicit since we can't stop MSVC warning about this in headers and to warn is the MSVC default. No functionality change.

llvm-svn: 192548

llvm-svn: 192545

llvm-svn: 192539

llvm-svn: 192325

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

llvm-svn: 192071

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: Provides the _LIBCPP_WARNING macro, to be used for MSVC only, since that compiler doesn't support #warning.

llvm-svn: 191980

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

llvm-svn: 191931

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

llvm-svn: 191127

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: 190478

llvm-svn: 189949

llvm-svn: 189772

llvm-svn: 189623

Turn off extern templates for most uses.  It is causing more problems than it is worth.  The extern templates will still be built into the dylib, mainly for ABI stability purposes.  And the client can still turn these back on with a #define if desire.  This fixes http://llvm.org/bugs/show_bug.cgi?id=17027.  However there's no associated test for the test suite because http://llvm.org/bugs/show_bug.cgi?id=17027 needs mismatched dylib and headers to fire.

llvm-svn: 189610

llvm-svn: 189273

llvm-svn: 189140

Debug mode for string.  This commit also marks the first time libc++ debug-mode has found a bug (found one in regex).  Had to play with extern templates a bit to get this to work since string is heavily used within libc++.dylib.

llvm-svn: 189114

llvm-svn: 189046

LWG 2145 - mark constructor for std::error_category as inline and constexpr. Leave the (existing, out-of-line, non-constexpr) in the dylib for compatibility with existing programs)

llvm-svn: 188858

llvm-svn: 188396

llvm-svn: 188395

Nico Rieck:  this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.

llvm-svn: 188192

1.  I had been detecting and trapping iterator == and \!= among iterators
    in different containers as an error.  But the trapping itself is actually
    an error.
    
    Consider:
    
    #include <iostream>
    #include <vector>
    #include <algorithm>

    template <class C>
    void
    display(const C& c)
    {
        std::cout << "{";
        bool first = true;
        for (const auto& x : c)
        {
            if (\!first)
                std::cout << ", ";
            first = false;
            std::cout << x;
        }
        std::cout << "}\n";
    }

    int
    main()
    {
        typedef std::vector<int> V;
        V v1 = {1, 3, 5};
        V v2 = {2, 4, 6};
        display(v1);
        display(v2);
        V::iterator i = std::find(v1.begin(), v1.end(), 1);
        V::iterator j = std::find(v2.begin(), v2.end(), 2);
        if (*i == *j)
            i = j;    // perfectly legal
        // ...
        if (i \!= j)   // the only way to check
            v2.push_back(*i);
        display(v1);
        display(v2);
    }

    It is legal to assign an iterator from one container to another of the
    same type.  This is required to work.  One might want to test whether or
    not such an assignment had been made.  The way one performs such a check
    is using the iterator's ==, \!= operator.  This is a logical and necessary
    function and does not constitute an error.

2.  I had a header circular dependence bug when _LIBCPP_DEBUG2 is defined.
    This caused a problem in several of the libc++ tests.
    Fixed.

3.  There is a serious problem when _LIBCPP_DEBUG2=1 at the moment in that
    std::basic_string is inoperable.  std::basic_string uses __wrap_iterator
    to implement its iterators.  __wrap_iterator has been rigged up in debug
    mode to support vector.  But string hasn't been rigged up yet.  This means
    that one gets false positives when using std::string in debug mode.  I've
    upped std::string's priority in www/debug_mode.html.

llvm-svn: 187636

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.

llvm-svn: 187593

llvm-svn: 187332

llvm-svn: 186951