Summary:
Exactly what the title says.
This patch also adds a `std::hash<nullptr_t>` specialization in C++17, but it was not added by this paper and I can't find the actual paper that adds it.
See http://wg21.link/P0513R0 for more info.
If there are no comments in the next couple of days I'll commit this
Reviewers: mclow.lists, K-ballo, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28938
llvm-svn: 292684
Summary: This patch adjusts the newly added `msvc_stdlib_force_include.hpp` so that it also works when used with `clang++`.
Reviewers: STL_MSFT
Reviewed By: STL_MSFT
Differential Revision: https://reviews.llvm.org/D28917
llvm-svn: 292539
No functional change; nothing includes this, instead our test harness
injects it via the /FI compiler option.
No code review; blessed in advance by EricWF.
llvm-svn: 292443
MSVC has compiler warnings C4127 "conditional expression is constant" (enabled
by /W4) and C6326 "Potential comparison of a constant with another constant"
(enabled by /analyze). They're potentially useful, although they're slightly
annoying to library devs who know what they're doing. In the latest version of
the compiler, C4127 is suppressed when the compiler sees simple tests like
"if (name_of_thing)", so extracting comparison expressions into named
constants is a workaround. At the same time, using std::integral_constant
avoids C6326, which doesn't look at template arguments.
test/std/containers/sequences/vector.bool/emplace.pass.cpp
Replace 1 == 1 with true, which is the same as far as the library is concerned.
Fixes D28837.
llvm-svn: 292432
Adding `path::operator=(string_type&&)` made the expression `p = {}`
ambiguous. This path fixes that ambiguity by making the `string&&`
overload a template so it ranks lower during overload resolution.
llvm-svn: 292345
This is the subject of an active NB comment. Regardless of what the Working
Paper currently says, asking this question is morally wrong, because the
answer can change when the type is completed. C1XX now detects such
precondition violations and complains about them; perhaps Clang should too.
Fixes D28591.
llvm-svn: 292281
When support for `basic_string_view` was added to string it also
added new assignment operators from `basic_string_view`. These caused
ambiguity when assigning from a braced initializer. This patch fixes
that regression by making the basic_string_view assignment operator
rank lower in overload resolution by making it a template.
llvm-svn: 292276
This patch contains multiple cleanups and fixes to better support building on
Windows.
* [Test] Fix handling of library runtime search paths by correctly adding them
to the PATH variable when running the tests.
* [Test] Don't explicitly force "--target=i686-pc-windows" when running the
test suite. Clang++ seems to deduce the correct target.
* [Test] Fix `.sh.cpp` tests on Windows by properly escaping flags used in
shell commands. Specifically windows style paths which included spaces
were causing these tests to fail.
* [CMake] Add "vcruntime" to the list of supported C++ ABI libraries in CMake, and
teach the test suite how to handle it. For now libc++ defaults to using
"vcruntime" on Windows except when libc++abi is in tree; That is probably
a bug and should be changed to always use vcruntime, at least for now.
* [Misc] Move the "c++-build" include directory to the libc++ binary dir
instead of the top level project dir and rename it "c++build". This is just
misc cleanup. Libc++ shouldn't be creating internal build files and directories
at the top-level projects root.
* [Misc] Build type_info's destructor when building for MSVC. This is a temporary
work around to prevent link errors until we have a proper type_info
implementation.
llvm-svn: 292157
Summary: This patch allows libc++ to be built against the debug MSVC runtimes instead of just the release ones.
Reviewers: rnk, majnemer, compnerd, smeenai
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D28725
llvm-svn: 292006
Summary:
This patch attempts to fix the libc++ build/link so that it doesn't use an default C++ libraries on Windows. This is needed to prevent linking to MSVC's STL library.
Additionally this patch changes libc++ so that it is always linked with the non-debug DLL's (e.g. `/MD`). This is needed so that the test suite can correctly link the same libraries without needing to know which configuration `c++.dll` was linked with.
Reviewers: compnerd, rnk, majnemer, kimgr, awson, halyavin, smeenai
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28441
llvm-svn: 292001
When -pedantic-errors is specified `__has_extension(<feature>)` is always
false when it would otherwise be true. This causes C++03 <atomic> to break
along with other issues.
This patch avoids the above problem by using __is_identifier(...) instead since
it is not affected by -pedantic-errors. For example instead of checking for
__has_extension(c_atomics) we now check `!__is_identifier(_Atomic)`, which
is only true when _Atomic is not a keyword provided by the compiler.
This patch applies similar changes to the detection logic for __decltype and
__nullptr as well.
Note that it does not apply this change to the C++03
`static_assert` macro since -Wc11-extensions warnings generated by expanding
that macro will appear in user code, and will not be suppressed as part of a
system header.
llvm-svn: 291995
Clang recently added a `diagnose_if(cond, msg, type)` attribute
which can be used to generate diagnostics when `cond` is a constant
expression that evaluates to true. Otherwise no attribute has no
effect.
This patch adds _LIBCPP_DIAGNOSE_ERROR/WARNING macros which
use this new attribute. Additionally this patch implements
a diagnostic message when a non-const-callable comparator is
given to a container.
Note: For now the warning version of the diagnostic is useless
within libc++ since warning diagnostics are suppressed by the
system header pragma. I'm going to work on fixing this.
llvm-svn: 291961
The destructor of std::promise needs to construct a std::future_error
exception so it calls std::make_exception_ptr. But under
libcpp-no-exceptions this will trigger an abort.
Differential Revision: https://reviews.llvm.org/D27614
llvm-svn: 291550
Windows is greedy and it defines the identifier `__out` as a macro.
This patch renames all conflicting libc++ identifiers in order
to correctly work on Windows.
llvm-svn: 291345
On Windows the runtime search path for DLL's is the same as PATH.
This patch changes the test suite to add the libc++ build directory
to the runtime PATH.
llvm-svn: 291309
Summary:
This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses.
The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API.
Reviewers: compnerd, rmaprath
Subscribers: smeenai, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28316
llvm-svn: 291275
This patch gets the test suite "working" on Windows, although
none of the tests pass.
In order to reuse the existing configuration, which uses UNIX
style flags not accepted by clang-cl, this patch only works with clang++.
When clang-cl is specified the test harness secretly looks for
clang++ and then it configures it using the INCLUDE and LIB enviroment
variables.
This is very much a work in progress.
llvm-svn: 291072
The test was previously set to XFAIL if __cpp_structured_bindings
wasn't defined. However there are Clang 4.0 versions which do not
define this macro but do provide structured bindings, which causes
the test to pass unexpectedly.
This patch changes the XFAIL to an UNSUPPORTED.
llvm-svn: 291060
In ABI v1 libc++ implements std::pointer_safety as a class type instead
of an enumeration. However this class type does not provide
a default constructor as it should. This patch adds that default constructor.
llvm-svn: 291059
In the C++ standard `std::pointer_safety` is defined
as a C++11 strongly typed enum. However libc++ currently defines
it as a class type which simulates a C++11 enumeration. This
can be detected in valid C++ code.
This patch introduces an the _LIBCPP_ABI_POINTER_SAFETY_ENUM_TYPE ABI option.
When defined `std::pointer_safety` is implemented as an enum type.
Unfortunatly this also means it can no longer be provided as an extension
in C++03.
Additionally this patch moves the definition for `get_pointer_safety()`
out of the dylib, and into the headers. New usages of `get_pointer_safety()`
will now use the inline version instead of the dylib version. However in
order to keep the dylib ABI compatible the old definition is explicitly
compiled into it.
llvm-svn: 291046
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
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
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
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
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=708http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2037.htm
Reviewed by: ericwf
Differential Revision: https://reviews.llvm.org/D21436
llvm-svn: 290748
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
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
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
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
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
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
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
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/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
This patch changes where the C++ ABI headers are put during the build. Previously
they were put in the top level include directory (not the libc++ header directory).
However that just polutes the top level directory. Instead this patch creates a special
directory to put them in. The reason they can't be put under c++/v1 until after the build
is because libc++ uses the in-source headers, so we can't add the include path of the libc++
headers in the object dir.
Additionally this patch teaches the test suite how to find the ABI headers,
and adds a demangling utility to help debug tests with.
llvm-svn: 289195
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
test/std/input.output/iostream.format/input.streams/istream.unformatted/get.pass.cpp
Add static_cast<char> because basic_istream::get() returns int_type (N4606 27.7.2.3 [istream.unformatted]/4).
test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minus1.pass.cpp
Add static_cast<char> because toupper() returns int (C11 7.4.2.2/1).
test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.ops/assign_t.pass.cpp
This test is intentionally writing doubles to ostream_iterator<int>.
It's silencing -Wliteral-conversion for Clang, so I'm adding C4244 silencing for MSVC.
test/std/language.support/support.limits/limits/numeric.limits.members/infinity.pass.cpp
Given `extern float zero;`, the expression `1./zero` has type double, which emits a truncation warning
when being passed to test<float>() taking float. The fix is to say `1.f/zero` which has type float.
test/std/numerics/complex.number/cmplx.over/arg.pass.cpp
test/std/numerics/complex.number/cmplx.over/norm.pass.cpp
These tests were constructing std::complex<double>(x, 0), emitting truncation warnings when x is long long.
Saying static_cast<double>(x) avoids this.
test/std/numerics/rand/rand.eng/rand.eng.lcong/seed_result_type.pass.cpp
This was using `int s` to construct and seed a linear_congruential_engine<T, stuff>, where T is
unsigned short/unsigned int/unsigned long/unsigned long long. That emits a truncation warning in the
unsigned short case. Because the range [0, 20) is tiny and we aren't doing anything else with the index,
we can just iterate with `T s`.
test/std/re/re.traits/value.pass.cpp
regex_traits<wchar_t>::value()'s first parameter is wchar_t (N4606 28.7 [re.traits]/13). This loop is
using int to iterate through ['g', 0xFFFF), emitting a truncation warning from int to wchar_t
(which is 16-bit for some of us). Because the bound is exclusive, we can just iterate with wchar_t.
test/std/strings/basic.string/string.cons/size_char_alloc.pass.cpp
This test is a little strange. It's trying to verify that basic_string's (InIt, InIt) range constructor
isn't confused by "N copies of C" when N and C have the same integral type. To do this, it was
testing (100, 65), but that eventually emits truncation warnings from int to char. There's a simple way
to avoid this - passing (static_cast<char>(100), static_cast<char>(65)) also exercises the disambiguation.
(And 100 is representable even when char has a signed range.)
test/std/strings/string.view/string.view.hash/string_view.pass.cpp
Add static_cast<char_type> because `'0' + i` has type int.
test/std/utilities/function.objects/bind/func.bind/func.bind.bind/nested.pass.cpp
What's more horrible than nested bind()? pow() overloads! This operator()(T a, T b) was assuming that
std::pow(a, b) can be returned as T. (In this case, T is int.) However, N4606 26.9.1 [cmath.syn]/2
says that pow(int, int) returns double, so this was truncating double to int.
Adding static_cast<T> silences this.
test/std/utilities/function.objects/unord.hash/integral.pass.cpp
This was iterating `for (int i = 0; i <= 5; ++i)` and constructing `T t(i);` but that's truncating
when T is short. (And super truncating when T is bool.) Adding static_cast<T> silences this.
test/std/utilities/utility/exchange/exchange.pass.cpp
First, this was exchanging 67.2 into an int, but that's inherently truncating.
Changing this to static_cast<short>(67) avoids the truncation while preserving the
"what if T and U are different" test coverage.
Second, this was exchanging {} with the explicit type float into an int, and that's also
inherently truncating. Specifying short is just as good.
test/std/utilities/utility/pairs/pairs.spec/make_pair.pass.cpp
Add static_cast<short>. Note that this affects template argument deduction for make_pair(),
better fulfilling the test's intent. For example, this was saying
`typedef std::pair<int, short> P1; P1 p1 = std::make_pair(3, 4);` but that was asking
make_pair() to return pair<int, int>, which was then being converted to pair<int, short>.
(pair's converting constructors are tested elsewhere.)
Now, std::make_pair(3, static_cast<short>(4)) actually returns pair<int, short>.
(There's still a conversion from pair<nullptr_t, short> to pair<unique_ptr<int>, short>.)
Fixes D27544.
llvm-svn: 289111
test/std/algorithms/alg.modifying.operations/alg.random.shuffle/random_shuffle_rand.pass.cpp
(Affects 64-bit architectures.) Include <cstddef> so we can take/return std::ptrdiff_t
(instead of int) in random_shuffle()'s RNG. (C++14 D.12 [depr.alg.random.shuffle]/2 says that
difference_type is used, and we're shuffling a plain array.)
test/std/algorithms/alg.sorting/alg.sort/sort/sort.pass.cpp
test/std/algorithms/alg.sorting/alg.sort/stable.sort/stable_sort.pass.cpp
(Affects 64-bit architectures.) Include <iterator> because we're already using iterator_traits.
Then, store the result of subtracting two RanIts as difference_type instead of long
(which truncates on LLP64 architectures like MSVC x64).
test/std/containers/sequences/forwardlist/forwardlist.ops/splice_after_flist.pass.cpp
test/std/containers/sequences/forwardlist/forwardlist.ops/splice_after_one.pass.cpp
(Affects 64-bit architectures.) Include <cstddef> so we can store the result of
subtracting two pointers as std::ptrdiff_t (instead of int).
test/std/input.output/iostream.format/input.streams/istream.unformatted/ignore_0xff.pass.cpp
(Affects 32-bit architectures.) Sometimes, size_t is too small. That's the case here,
where tellg() returns pos_type (N4606 27.7.2.3 [istream.unformatted]/39). Implementations can
have 64-bit pos_type (to handle large files) even when they have 32-bit size_t.
Fixes D27543.
llvm-svn: 289110
Instead of storing double in double and then truncating to int, store int in long
and then widen to long long. This preserves test coverage (as these tests are
interested in various tuple conversions) while avoiding truncation warnings.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/const_pair.pass.cpp
Since we aren't physically truncating anymore, t1 is equal to p0.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/convert_copy.pass.cpp
One edit is different from the usual pattern. Previously, we were storing
double in double and then converting to A, which has an implicitly converting
constructor from int. Now, we're storing int in int and then converting to A,
avoiding the truncation.
Fixes D27542.
llvm-svn: 289109
Change char to long and remove some char casts. This preserves test coverage for tuple's
heterogeneous comparisons, while avoiding int-to-char truncation warnings.
Fixes D27541.
llvm-svn: 289108
These tests for some guy's transparent operator functors were needlessly truncating their
double results to int. Preserving the doubleness makes compilers happier. I'm following
existing practice by adding an "// exact in binary" comment when the result isn't a whole number.
(The changes from 6 to 6.0 and so forth are stylistic, not critical.)
Fixes D27539.
llvm-svn: 289106
Given `std::basic_streambuf<CharT>::int_type __c`, `std::basic_string<CharT> str_`,
and having checked `__c != std::basic_streambuf<CharT>::traits_type::eof()` (substituting typedefs
for clarity), the line `str_.push_back(__c);` is safe according to humans, but truncates according
to compilers. `str_.push_back(static_cast<CharT>(__c));` avoids that problem.
Fixes D27538.
llvm-svn: 289105
test/std/containers/sequences/vector.bool/copy.pass.cpp
test/std/containers/sequences/vector.bool/copy_alloc.pass.cpp
test/std/containers/sequences/vector/vector.cons/copy.pass.cpp
test/std/containers/sequences/vector/vector.cons/copy_alloc.pass.cpp
Change "unsigned s = x.size();" to "typename C::size_type s = x.size();"
because that's what it returns.
test/std/strings/basic.string/string.cons/pointer_alloc.pass.cpp
Include <cstddef>, then change "unsigned n = T::length(s);"
to "std::size_t n = T::length(s);" because that's what char_traits returns.
test/std/strings/basic.string/string.cons/substr.pass.cpp
Change unsigned to typename S::size_type because that's what str.size() returns.
test/std/utilities/template.bitset/bitset.cons/ull_ctor.pass.cpp
This was needlessly truncating std::size_t to unsigned.
It's being used to compare and initialize std::size_t.
llvm-svn: 288753
Use static_cast<int> when storing size_t in int (or passing size_t to int).
Also, remove a spurious semicolon in test/support/archetypes.hpp.
test/support/count_new.hpp
Additionally, change data members (and parameters) to size_t.
llvm-svn: 288752
Replace "int n = str_.size();" with "int n = static_cast<int>(str_.size());".
int is the correct type to use, because we're eventually calling
"base::pbump(n+1);" where base is std::basic_streambuf.
N4606 27.6.3.3.3 [streambuf.put.area]/4 declares: "void pbump(int n);"
llvm-svn: 288751
Various changes:
test/std/algorithms/alg.sorting/alg.merge/inplace_merge.pass.cpp
This is comparing value_type to unsigned. value_type is sometimes int and sometimes struct S (implicitly constructible from int).
static_cast<value_type>(unsigned) silences the warning and doesn't do anything bad (as the values in question are small).
test/std/algorithms/alg.sorting/alg.nth.element/nth_element_comp.pass.cpp
This is comparing an int remote-element to size_t. The values in question are small and non-negative,
so either type is fine. I think that converting int to size_t is marginally better here than the reverse.
test/std/containers/sequences/deque/deque.cons/size.pass.cpp
DefaultOnly::count is int (and non-negative). When comparing to unsigned, use static_cast<unsigned>.
test/std/strings/basic.string/string.access/index.pass.cpp
We're comparing char to '0' through '9', but formed with the type size_t. Add static_cast<char>.
test/std/utilities/template.bitset/bitset.cons/ull_ctor.pass.cpp
Include <cstddef> for pedantic correctness (this test was already mentioning std::size_t).
"v[i] == (i & 1)" was comparing bool to size_t. Saying "v[i] == ((i & 1) != 0)" smashes the RHS to bool.
llvm-svn: 288749
Change "unsigned n = 0;" to "int n = 0;". It's being compared to int elements and ptrdiff_t distances.
test/std/containers/sequences/forwardlist/forwardlist.cons/move.pass.cpp
This one's a little special, but not really. "*i == n" is comparing MoveOnly to n.
MoveOnly is implicitly constructible from int, so int is the correct type to use here.
llvm-svn: 288748
Add static_cast<int>. In these cases, the values are guaranteed to be small-ish,
and they're being compared to int elements.
test/std/containers/sequences/deque/deque.capacity/access.pass.cpp
Use int instead of unsigned to iterate from 0 to 10.
llvm-svn: 288747
Add static_cast<std::size_t> to more comparisons. (Performed manually, unlike part 8/12.)
Also, include <cstddef> when it wasn't already being included.
llvm-svn: 288746
The Clang modules implementation breaks enough that libc++ needs an easy way
to enable/disable using modules on the Zorg builders. Editing Zorg itself
requires a buildmaster restart which only happens weekly. This patch
allows LIBCXX_USE_MODULES to be used to enable/disable the feature,
allowing the buildslave to disable it as need be.
llvm-svn: 288736
This patch overhalls the libc++ test format/configuration in order to fully support modules. By "fully support" I mean get almost all of the tests passing. The main hurdle for doing this is handling tests that `#define _LIBCPP_FOO` macros to test a different configuration. This patch deals with these tests in the following ways:
1. For tests that define single `_LIBCPP_ABI_FOO` macros have been annotated with `// MODULES_DEFINES: _LIBCPP_ABI_FOO`. This allows the test suite to define the macro on the command line so it uses a different set of modules.
2. Tests for libc++'s debug mode (which define custom `_LIBCPP_ASSERT`) are automatically detected by the test suite and are compiled and run with modules disabled.
This patch also cleans up how the `CXXCompiler` helper class handles enabling/disabling language features.
NOTE: This patch uses `LIT` features which were only committed to LLVM today. If this patch breaks running the libc++ tests you probably need to update LLVM.
llvm-svn: 288728
Under libcpp-no-exceptions, noexcept is trivially true. Some tests expect in
the usual setting to return false, so adjust them to expect true under
libcpp-no-exceptions.
Differential Revision: https://reviews.llvm.org/D27310
llvm-svn: 288660
Replace throw with TEST_THROW and protect tests that do throw. Also add missing assert(false).
Differential Revision: https://reviews.llvm.org/D27252
llvm-svn: 288383
When initializing unsigned integers to their maximum values, change "const T M(~0);" to "const T M(static_cast<T>(-1));".
~0 and -1 are equivalent, but I consider the -1 form to be significantly clearer (and more consistent with other tests).
llvm-svn: 287827
Various changes:
test/std/algorithms/alg.sorting/alg.binary.search/binary.search/binary_search.pass.cpp
Change M from unsigned to int. It's compared against "int x",
and we binary_search() for it within a vector<int>.
test/std/numerics/rand/rand.dis/rand.dist.norm/rand.dist.norm.f/eval.pass.cpp
test/std/numerics/rand/rand.dis/rand.dist.norm/rand.dist.norm.f/eval_param.pass.cpp
Add static_cast<unsigned> when comparing int to unsigned.
test/std/strings/basic.string/string.cons/size_char_alloc.pass.cpp
Change unsigned indices to int when we're being given int as a bound.
llvm-svn: 287825
Summary: The `max_size()` method of containers should respect both the allocator's reported `max_size` and the range of the `difference_type`. This patch makes all containers choose the smallest of those two values.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26885
llvm-svn: 287729
Summary:
Because `locale.h` isn't part of the libc++ modules the class definitions it provides are exported as part of `__locale` (since it happens to be build first). This breaks `<clocale>` which exports `std::lconv` without including `<__locale>`.
This patch implements `locale.h` to fix this issue, it also adds support for testing libc++ with modules.
Reviewers: mclow.lists, rsmith, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D26826
llvm-svn: 287413
In C++11 mode and newer, use real static_asserts.
In C++03 mode, min() and max() aren't constexpr, so use plain asserts.
One test triggers MSVC's warning C4310 "cast truncates constant value".
The code is valid, and yet the warning is valid, so I'm silencing it
through push-disable-pop.
llvm-svn: 287391
sample() isn't specified with a reproducible algorithm, so expecting
exact output is non-Standard. Mark those tests with LIBCPP_ASSERT.
In test_small_population(), we're guaranteed to get all of the elements,
but not necessarily in their original order. When PopulationCategory is
forward, we're guaranteed stability (and can therefore test equal()).
Otherwise, we can only test is_permutation(). (As it happens, both libcxx
and MSVC's STL provide stability in this scenario for input-only iterators.)
llvm-svn: 287383
The Standard doesn't provide any guarantees beyond "valid but unspecified" for
moved-from std::functions. libcxx moves from small targets and leaves them
there, while MSVC's STL empties out the source. Mark these assertions as
libcxx-specific.
llvm-svn: 287382
N4582 17.6.3.5 [allocator.requirements] says that allocators are given
cv-unqualified object types, and N4582 20.9.9 [default.allocator]
implies that allocator<const T> is ill-formed (due to colliding
address() overloads). Therefore, tests for allocator<const T>
should be marked as libcxx-specific (if not removed outright).
llvm-svn: 287381
This fails with gcc because __builtin_isnan and friends, which
libcpp_isnan and friends call, are not themselves constexpr-evaluatable.
llvm-svn: 287041
Summary:
This makes these functions available on host and device, which is
necessary to compile <complex> for the device.
Reviewers: hfinkel, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25403
llvm-svn: 287012
With a max_load_factor of 1.0, the only guarantee is that
bucket_count() >= size(). (Note: setting max_load_factor without
rehashing isn't supposed to affect this, because setting
max_load_factor is currently specified to be constant time.)
llvm-svn: 286982
test/std/depr/depr.c.headers/inttypes_h.pass.cpp
test/std/input.output/file.streams/c.files/cinttypes.pass.cpp
test/std/input.output/iostream.forward/iosfwd.pass.cpp
Add test() to avoid a bunch of void-casts, although we still need a few.
test/std/input.output/iostream.format/quoted.manip/quoted.pass.cpp
skippingws was unused (it's unclear to me whether this was mistakenly copy-pasted from round_trip() below).
test/std/localization/locale.categories/category.collate/locale.collate/types.pass.cpp
test/std/localization/locale.categories/category.ctype/facet.ctype.special/types.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.codecvt/types_char.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.codecvt/types_wchar_t.pass.cpp
test/std/localization/locale.categories/category.ctype/locale.ctype/types.pass.cpp
test/std/localization/locale.categories/facet.numpunct/locale.numpunct/types.pass.cpp
test/std/localization/locales/locale.global.templates/use_facet.pass.cpp
When retrieving facets, the references are unused.
test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_long.pass.cpp
test/std/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_unsigned_long.pass.cpp
"std::ios_base::iostate err = ios.goodbit;" was completely unused here.
test/std/localization/locale.categories/category.time/locale.time.get/time_base.pass.cpp
test/std/numerics/c.math/ctgmath.pass.cpp
test/std/numerics/rand/rand.device/entropy.pass.cpp
test/std/numerics/rand/rand.device/eval.pass.cpp
test/std/strings/basic.string/string.modifiers/string_copy/copy.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/eof.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/eof.pass.cpp
test/std/thread/futures/futures.promise/dtor.pass.cpp
test/std/thread/futures/futures.task/futures.task.members/dtor.pass.cpp
test/std/thread/thread.condition/thread.condition.condvar/wait_for_pred.pass.cpp
These variables are verifying types but are otherwise unused.
test/std/strings/basic.string/string.capacity/reserve.pass.cpp
old_cap was unused (it's unclear to me whether it was intended to be used).
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/lt.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/lt.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/eq.pass.cpp
test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/lt.pass.cpp
These tests contained unused characters.
llvm-svn: 286847
Skip tests that expect an exception be thrown. Also add
some missing asserts in the original test.
Differential Revision: https://reviews.llvm.org/D26512
llvm-svn: 286823
Bitset tests feature a sequence of tests of increasing bitset sizes,
but these tests rely on exceptions when the bitset size is less than
50 elements.
This change adds a flag to tell whether a test should throw. If it must
throw it will be skipped under no-exceptions.
Differential Revision: https://reviews.llvm.org/D26140
llvm-svn: 286474
In these tests there are some paths that explicitly throw, so use
the TEST_THROW macro that was proposed for this and then skip the tests
that may enter the throwing path.
Differential Revision: https://reviews.llvm.org/D26142
llvm-svn: 286099
This replaces every occurrence of _LIBCPP_STD_VER in the tests with
TEST_STD_VER. Additionally, for every affected
file, #include "test_macros.h" is being added explicitly if it wasn't
already there.
https://reviews.llvm.org/D26294
llvm-svn: 286007
Skip the tests that expect an exception be thrown and protect unreachable catch blocks.
Differential Revision: https://reviews.llvm.org/D26197
llvm-svn: 285791
Previously __libcpp_is_constructible checked the validity of reference
construction using 'eat<To>(declval<From>())' but this doesn't consider
From's explicit conversion operators. This patch teaches __libcpp_is_constructible
how to handle these cases. To do this we need to check the validity
using 'static_cast<To>(declval<From>())'. Unfortunately static_cast allows
additional base-to-derived and lvalue-to-rvalue conversions, which have to be
checked for and manually rejected.
While implementing these changes I discovered that Clang incorrectly
rejects `static_cast<int&&>(declval<float&>())` even though
`int &&X(declval<float&>())` is well formed. In order to tolerate this bug
the `__eat<T>(...)` needs to be left in-place. Otherwise it could be replaced
entirely with the new static_cast implementation.
Thanks to Walter Brown for providing the test cases.
llvm-svn: 285786
These tests are of the form
try {
action-that-may-throw
assert(!exceptional-condition)
assert(some-other-facts)
} catch (relevant-exception) {
assert(exceptional-condition)
}
Under libcpp-no-exceptions there is still value in verifying
some-other-facts while avoiding the exceptional case. So for these tests
just conditionally check some-other-facts if exceptional-condition is
false. When exception are supported make sure that a true
exceptional-condition throws an exception
Differential Revision: https://reviews.llvm.org/D26136
llvm-svn: 285697
Under -fno-exceptions TEST_THROW becomes abort / __builtin_abort which returns
void. This causes a type mismatch in the conditional operator when testing the
library in C++98,03,11 modes.
Use a comma operator to workaround this problem.
Differential Revision: https://reviews.llvm.org/D26147
llvm-svn: 285572
This is a follow up of D24562.
These tests do not check anything but exceptions, so it makes sense to mark
them as UNSUPPORTED under a library built without exceptions.
Differential Revision: https://reviews.llvm.org/D26075
llvm-svn: 285550
This prevent the symbols from being both externally available and hidden, which
causes them to be linked incorrectly. This is only a problem when the address
of the function is explicitly taken since it will always be inlined otherwise.
This patch fixes the issues that caused r285456 to be reverted, and can
now be reapplied.
llvm-svn: 285531
This patch entirely rewrites the parsing logic for paths. Unlike the previous
implementation this one stores information about the current state; For example
if we are in a trailing separator or a root separator. This avoids the need for
extra lookahead (and extra work) when incrementing or decrementing an iterator.
Roughly this gives us a 15% speedup over the previous implementation.
Unfortunately this implementation is still a lot slower than libstdc++'s.
Because libstdc++ pre-parses and splits the path upon construction their
iterators are trivial to increment/decrement. This makes libc++ lazy parsing
100x slower than libstdc++. However the pre-parsing libstdc++ causes a ton
of extra and unneeded allocations when constructing the string. For example
`path("/foo/bar/")` would require at least 5 allocations with libstdc++
whereas libc++ uses only one. The non-allocating behavior is much preferable
when you consider filesystem usages like 'exists("/foo/bar/")'.
Even then libc++'s path seems to be twice as slow to simply construct compared
to libstdc++. More investigation is needed about this.
llvm-svn: 285526
This patch does two seperate things. First it adds a file called
"__libcpp_version" which only contains the current libc++ version
(currently 4000). This file is not intended for use as a header. This file
is used by Clang in order to easily determine the installed libc++ version.
This allows Clang to enable/disable certain language features only when the
library supports them.
The second change is the addition of _LIBCPP_LIBRARY_VERSION macro, which
returns the version of the installed dylib since it may be different than
the headers.
llvm-svn: 285382
Summary:
Fixes PR19851.
alg.re.match/ecma.pass.cpp still XFAILS on linux, but after commenting out
locale-related tests, it passes. I don't have a freebsd machine to produce a
full pass.
Reviewers: mclow.lists
Subscribers: cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D26026
llvm-svn: 285352
Fixes MS issues 63, 64, and 65.
test/std/utilities/any/any.class/any.cons/move.pass.cpp:
* "Moves are always destructive" is not a portable assumption; check with LIBCPP_ASSERT.
test/std/utilities/any/any.class/any.cons/value.pass.cpp:
* The standard does not forbid initializing std::any from any pointer-to-function type. Remove the non-conforming "DecayTag" test.
test/std/utilities/any/any.class/any.modifiers/swap.pass.cpp:
* Self-swap is not specified to perform no moves; check with LIBCPP_ASSERT.
Differential Revision: https://reviews.llvm.org/D26007
llvm-svn: 285234
Eric Fiselier