| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 291021
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bindings
Summary:
This patch attempts to re-implement a fix for LWG 2770, but not the actual specified PR.
The PR for 2770 specifies tuple_size<T const> as only conditionally providing a `::value` member. However C++17 structured bindings require `tuple_size<T const>` to be complete only if `tuple_size<T>` is also complete. Therefore this patch implements only provides the specialization `tuple_size<T CV>` iff `tuple_size<T>` is a complete type.
This fixes http://llvm.org/PR31513.
Reviewers: mclow.lists, rsmith, mpark
Subscribers: mpark, cfe-commits
Differential Revision: https://reviews.llvm.org/D28222
llvm-svn: 291019
|
|
|
|
|
|
| |
reverse_iterator, move_iterator, array and Range Access' for C++17
llvm-svn: 290976
|
|
|
|
|
|
| |
Fixes D27786.
llvm-svn: 290922
|
|
|
|
|
|
|
|
|
|
| |
These tests were using malloc()'s return value without checking for null,
which MSVC's /analyze rightly warns about. Asserting that the pointer is
non-null both expresses the test's intention and silences the warning.
Fixes D27785.
llvm-svn: 290921
|
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D27576
Reviewers: EricWF
llvm-svn: 290889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
after r290850
Before r290850, building libcxx with -DLIBCXX_HAS_EXTERNAL_THREAD_API=ON had two
uses:
- Allow platform vendors to plug-in an __external_threading header which
should take care of the entire threading infrastructure of libcxx
- Allow testing of an externally-threaded library build; where the thread API
is declared using pthread data structures, and the implementation of this
API is provided as a separate library (test/support/external_threads.cpp)
and linked-in when running the test suite.
r290850 breaks the second use case (pthread data structures are no longer
available). This patch re-stores the ability to build+test an
externally-threaded library variant on a pthread based system.
llvm-svn: 290878
|
|
|
|
|
|
|
|
|
| |
Refactor the header to allow us to implement alternate threading models
with alternate data structures. Take the opportunity to clang-format
the area. This will allow us to avoid re-declaring the interfaces for
Win32 threading. NFC
llvm-svn: 290850
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch re-commits a previous attempt to support building libc++ w/o
an ABI library. That patch was originally reverted because:
1) It forgot to teach the test suite about "default" ABI libraries.
2) Some LLVM builders don't clear the CMake cache between builds. The previous
patch caused those builders to fail since their old cache entry for
LIBCXX_CXX_ABI="" is no longer valid.
The updated patch addresses both issues. It works around (2) by adding
a hack to force the builders to update their cache entries. The hack will
be removed shortly once all LLVM builders have run.
Original commit message
-----------------------
Typically libc++ uses libc++abi or libcxxrt to provide the ABI and runtime bits
of the C++ STL. However we also support building w/o an ABI library entirely.
This patch fixes building libc++ w/o an ABI library (and incorporates the
`~type_info()` fix in D28211).
The main changes in this patch are:
1) Add `-DLIBCXX_CXX_ABI=default` instead of using the empty string to mean "default".
2) Fix CMake bits which treated "none" as "default" on OS X.
3) Teach the source files to respect `-D_LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY`.
4) Define ~type_info() when _LIBCPP_BUILDING_HAS_NO_ABI_LIBRARY is defined.
Unfortunately this patch doesn't help clean up the macro mess that we use to
configure for different ABI libraries.
llvm-svn: 290849
|
|
|
|
|
|
|
| |
This patch implements the correct PR for LWG 2770. It also makes the primary
tuple_size template incomplete again which fixes part of llvm.org/PR31513.
llvm-svn: 290846
|
|
|
|
| |
llvm-svn: 290758
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were two problems with the initial fix.
1. The added tests flushed out that we misconfigured _LIBCPP_EXPLICIT with GCC.
2. Because the boolean type was a member function template it caused weird link
errors. I'm assuming due to the vague linkage rules. This time the bool type
is a non-template member function pointer. That seems to have fixed the
failing tests. Plus it will end up generating less symbols overall, since
the bool type is no longer per instantiation.
original commit message below
-----------------------------
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
llvm-svn: 290754
|
|
|
|
| |
llvm-svn: 290752
|
|
|
|
| |
llvm-svn: 290751
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
llvm-svn: 290750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Back in r240527 I added a knob to prevent thread-unsafe functions from
being exposed. mblen(), mbtowc() and wctomb() were also added to this
list, as the latest issue of POSIX doesn't require these functions to be
thread-safe.
It turns out that the only circumstance in which these functions are not
thread-safe is in case they are used in combination with state-dependent
character sets (e.g., Shift-JIS). According to Austin Group Bug 708,
these character sets "[...] are mostly a relic of the past and which
were never supported on most POSIX systems".
Though in many cases the use of these functions can be prevented by
using the reentrant counterparts, they are the only functions that allow
you to query whether the locale's character set is state-dependent. This
means that omitting these functions removes actual functionality.
Let's be a bit less pedantic and drop the guards around these functions.
Links:
http://austingroupbugs.net/view.php?id=708
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2037.htm
Reviewed by: ericwf
Differential Revision: https://reviews.llvm.org/D21436
llvm-svn: 290748
|
|
|
|
| |
llvm-svn: 290746
|
|
|
|
| |
llvm-svn: 290721
|
|
|
|
| |
llvm-svn: 290657
|
|
|
|
| |
llvm-svn: 290655
|
|
|
|
| |
llvm-svn: 290653
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements changes to allow _LIBCPP_ASSERT to throw on failure
instead of aborting. The main changes needed to do this are:
1. Change _LIBCPP_ASSERT to call a handler via a replacable function pointer
instead of calling abort directly. Additionally this patch implements two
handler functions, one which aborts and another that throws an exception.
2. Add _NOEXCEPT_DEBUG macro for disabling noexcept spec on function which
contain _LIBCPP_ASSERT. This is required in order to prevent assertion
failures throwing through a noexcept function. This macro has no effect
unless _LIBCPP_DEBUG_USE_EXCEPTIONS is defined.
Having a non-aborting _LIBCPP_ASSERT is very important to allow sane testing of
debug mode. Currently we can only have one test case per file, since the test
case will cause the program to abort. Testing debug mode this way would require
thousands of test files, most of which would be 95% boiler plate. I don't think
this is a feasible strategy. Fortunately using a throwing debug handler solves
these issues.
Additionally this patch rewrites the documentation for debug mode.
llvm-svn: 290651
|
|
|
|
| |
llvm-svn: 290627
|
|
|
|
| |
llvm-svn: 290624
|
|
|
|
|
|
| |
Thanks to Karen for the report.
llvm-svn: 290500
|
|
|
|
| |
llvm-svn: 290486
|
|
|
|
| |
llvm-svn: 290482
|
|
|
|
| |
llvm-svn: 290481
|
|
|
|
| |
llvm-svn: 290480
|
|
|
|
| |
llvm-svn: 290477
|
|
|
|
| |
llvm-svn: 290476
|
|
|
|
| |
llvm-svn: 290475
|
|
|
|
| |
llvm-svn: 290474
|
|
|
|
| |
llvm-svn: 290473
|
|
|
|
| |
llvm-svn: 290472
|
|
|
|
| |
llvm-svn: 290470
|
|
|
|
| |
llvm-svn: 290469
|
|
|
|
| |
llvm-svn: 290459
|
|
|
|
| |
llvm-svn: 290446
|
|
|
|
| |
llvm-svn: 290445
|
|
|
|
|
|
| |
Michael Park
llvm-svn: 290440
|
|
|
|
| |
llvm-svn: 289802
|
|
|
|
| |
llvm-svn: 289781
|
|
|
|
| |
llvm-svn: 289780
|
|
|
|
| |
llvm-svn: 289778
|
|
|
|
| |
llvm-svn: 289774
|
|
|
|
|
|
|
|
| |
This patch reverts the changes to tuple which fixed construction from
types derived from tuple. It breaks the code mentioned in llvm.org/PR31384.
I'll follow this commit up with a test case.
llvm-svn: 289773
|
|
|
|
| |
llvm-svn: 289767
|
|
|
|
| |
llvm-svn: 289741
|
|
|
|
|
|
|
|
|
|
|
|
| |
allocator.
In list::remove we collect the nodes we're removing in a seperate
list instance. However we construct this list using the default
constructor which default constructs the allocator. However allocators
are not required to be default constructible. This patch fixes the
construction of the second list.
llvm-svn: 289735
|