| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
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: 290627
|
| |
|
|
| |
llvm-svn: 290624
|
| |
|
|
|
|
| |
Thanks to Karen for the report.
llvm-svn: 290500
|
| |
|
|
| |
llvm-svn: 290486
|
| |
|
|
| |
llvm-svn: 290481
|
| |
|
|
| |
llvm-svn: 290480
|
| |
|
|
| |
llvm-svn: 290477
|
| |
|
|
| |
llvm-svn: 290476
|
| |
|
|
| |
llvm-svn: 290475
|
| |
|
|
| |
llvm-svn: 290474
|
| |
|
|
| |
llvm-svn: 290472
|
| |
|
|
| |
llvm-svn: 290459
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
size_type/difference_type.
test/std/containers/container.adaptors/queue/queue.cons.alloc/ctor_container_alloc.pass.cpp
test/std/containers/container.adaptors/stack/stack.cons.alloc/ctor_container_alloc.pass.cpp
Iterate with C::size_type because that's what operator[] takes.
test/std/containers/sequences/vector/contiguous.pass.cpp
test/std/strings/basic.string/string.require/contiguous.pass.cpp
Add static_cast<typename C::difference_type> because that's what the iterator's operator+ takes.
Fixes D27777.
llvm-svn: 289734
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
tuple/pair/array.
Summary:
The standard requires tuple have the following constructors:
```
tuple(tuple<OtherTypes...> const&);
tuple(tuple<OtherTypes...> &&);
tuple(pair<T1, T2> const&);
tuple(pair<T1, T2> &&);
tuple(array<T, N> const&);
tuple(array<T, N> &&);
```
However libc++ implements these as a single constructor with the signature:
```
template <class TupleLike, enable_if_t<__is_tuple_like<TupleLike>::value>>
tuple(TupleLike&&);
```
This causes the constructor to reject types derived from tuple-like types; Unlike if we had all of the concrete overloads, because they cause the derived->base conversion in the signature.
This patch fixes this issue by detecting derived types and the tuple-like base they are derived from. It does this by creating an overloaded function with signatures for each of tuple/pair/array and checking if the possibly derived type can convert to any of them.
This patch fixes [PR17550]( https://llvm.org/bugs/show_bug.cgi?id=17550)
This patch
Reviewers: mclow.lists, K-ballo, mpark, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27606
llvm-svn: 289727
|
| |
|
|
| |
llvm-svn: 289716
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scoped_allocator_adaptor::construct(pair<T, U>*, ...) overloads.
Summary:
For more information see:
* https://llvm.org/bugs/show_bug.cgi?id=23841
* https://llvm.org/bugs/show_bug.cgi?id=24075
I hope you have as much fun reviewing as I did writing these insane tests!
Reviewers: mclow.lists, AlisdairM, EricWF
Subscribers: AlisdairM, Potatoswatter, cfe-commits
Differential Revision: https://reviews.llvm.org/D27612
llvm-svn: 289710
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nullptr_t and istream_iterator.
No code changes were needed, but I updated a few tests.
Also resolved P0509 and P0521, which required no changes to the library or tests.
This patch was reverted due to llvm.org/PR31016. There is a bug in Clang 3.7
which causes default.pass.cpp to fails. That test is now marked as XFAIL for that
clang version.
This patch was originally authored by Marshall Clow.
llvm-svn: 289708
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After r289363, these tests were triggering MSVC x64 warning C4267
"conversion from 'size_t' to 'int', possible loss of data" by taking 0, 2, and 10
as std::size_t, then constructing error_code(int, const error_category&) or
error_condition(int, const error_category&) from that (N4618 19.5.3.2
[syserr.errcode.constructors]/3, 19.5.4.2 [syserr.errcondition.constructors]/3).
The fix is simple: take these ints as int, pass them to the int-taking
constructor, and perform a value-preserving static_cast<std::size_t>
when comparing them to `std::size_t result`.
Fixes D27691.
llvm-svn: 289512
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Certain source control systems like to set the read-only bit on their files,
which interferes with opening "test.dat" for both input and output.
Fortunately, we can work around this without losing test coverage.
Now, the ifstream.cons tests have comments referring to the ofstream.cons tests.
There, we're creating writable files (not checked into source control),
where the ifstream constructor tests will succeed.
Fixes D26814.
llvm-svn: 289463
|
| |
|
|
|
|
|
|
| |
Value-initialized iterators still can't be compared to those with parents.
Fixes D26626.
llvm-svn: 289462
|
| |
|
|
| |
llvm-svn: 289363
|
| |
|
|
| |
llvm-svn: 289359
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These swap tests were swapping non-POCS non-equal allocators which
is undefined behavior. This patch changes the tests to use allocators
which compare equal. In order to test that the allocators were not
swapped I added an "id" field to test_allocator which does not
participate in equality but does propagate across copies/swaps.
This patch is based off of D26623 which was submitted by STL.
llvm-svn: 289358
|
| |
|
|
| |
llvm-svn: 289357
|
| |
|
|
| |
llvm-svn: 289356
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
moneypunct_byname and numpunct_byname.
Summary:
The underlying C locales provide the `thousands_sep` and `decimal_point` as strings, possible with more than one character. We currently don't handle this case even for `wchar_t`.
This patch properly converts the mbs -> wide character for `moneypunct_byname<wchar_t>`. For the `moneypunct_byname<char>` case we attempt to narrow the WC and if that fails we also attempt to translate it to some reasonable value. For example we translate U00A0 (non-breaking space) into U0020 (regular space). If none of these conversions succeed then we simply allow the base class to provide a fallback value.
Reviewers: mclow.lists, EricWF
Subscribers: vangyzen, george.burgess.iv, cfe-commits
Differential Revision: https://reviews.llvm.org/D24218
llvm-svn: 289347
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test/std/strings/string.view/string.view.ops/compare.pointer_size.pass.cpp
Passing -1 to size_t triggers signed/unsigned mismatch warnings because it's
a value-modifying conversion. Add static_cast<size_t> to soothe the compiler.
(This file refers to size_t unqualified.)
test/std/strings/string.view/string.view.ops/substr.pass.cpp
Add <algorithm> for std::min() and <stdexcept> for std::out_of_range.
N4618 21.4.2.4 [string.view.access]/1: "Requires: pos < size()."
/4: "[ Note: Unlike basic_string::operator[], basic_string_view::operator[](size())
has undefined behavior instead of returning charT(). -end note ]"
Fixes D27633.
llvm-svn: 289283
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
remove an unused variable.
test/support/test_macros.h
For convenience/greppability, add macros for libcxx-specific static_asserts about noexceptness.
(Moving the definitions of ASSERT_NOEXCEPT/ASSERT_NOT_NOEXCEPT isn't technically necessary
because they're macros, but I think it's better style to define stuff before using it.)
test/std/utilities/tuple/tuple.tuple/tuple.apply/apply.pass.cpp
There was a completely unused `TrackedCallable obj;`.
apply() isn't depicted with conditional noexcept in C++17.
test/std/utilities/tuple/tuple.tuple/tuple.apply/make_from_tuple.pass.cpp
Now that we have LIBCPP_ASSERT_NOEXCEPT, use it.
Fixes D27622.
llvm-svn: 289264
|
| |
|
|
| |
llvm-svn: 289204
|
| |
|
|
| |
llvm-svn: 289197
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes libc++'s tuple extension which allowed it to be
constructed from fewer initializers than elements; with the remaining
elements being default constructed. However the implicit version of
this extension breaks conforming code. For example:
int fun(std::string);
int fun(std::tuple<std::string, int>);
int x = fun("hello"); // ambigious
Because existing code may already depend on this extension it can be re-enabled
by defining _LIBCPP_ENABLE_TUPLE_IMPLICIT_REDUCED_ARITY_EXTENSION.
Note that the explicit version of this extension is still supported,
although it's somewhat less useful than the implicit one.
llvm-svn: 289158
|