When libcxx isn't building with an installed LLVM we copy the libcxx headers into the LLVM build directory so that a clang in that build tree can find the headers relative to itself.
This is only important in situations where you don't have headers installed under /, which is common these days on Darwin.
llvm-svn: 289963
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
Reverting because I didn't properly test this patch. Although it's probably
correct to add a stdbool_h module I thought the change fixed more than it did.
I'll re-commit after more investigation.
llvm-svn: 288789
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
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++ static to include in another library,
and we don't want any libc++ functions getting exported out of that
library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26934
llvm-svn: 288690
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
Previously these hashes were 0 and -1 respectively. These seem like common
sentinel values and should be avoided to prevent needless collisions.
This patch changes those values to different arbitrary numbers, which should
hopefully cause less collisions. Because I couldn't help myself I choose the
fundamental constants for gravity and the speed of light.
llvm-svn: 288623
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
The function definitions being guarded by the pragma were all static, so
they wouldn't be exported anyway. In any case, we should prefer the
visibility macros. No functional change.
Differential Revision: https://reviews.llvm.org/D26940
llvm-svn: 287768
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
Libc++ internal uses <atomic> in C++03 code but the module map forbids its use.
This causes the libc++ 'std' module to fail to build in C++03.
This patch removes the requirement to fix this issue.
llvm-svn: 287693
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
The code cannot currently link when using libsupc++ with the
LIBCXX_ENABLE_STATIC_ABI_LIBRARY option.
This change ifdef's out the the destructor and 'what' function for
bad_array_length and bad_array_new_length when GLIBCXX is defined.
The constructors that are left in are the only functions not being provided by
libsupc++ itself, and follows the same pattern that was used to ifdef bad_alloc.
Testing was done on a Linux x86_64 host using GCC 5.4 and libc++ from ToT.
I see no change to the test results when using libsup++ or libstdc++ without
LIBCXX_ENABLE_STATIC_ABI_LIBRARY. When using libsupc++ with
LIBCXX_ENABLE_STATIC_ABI_LIBRARY it will now build and test results are the
same as those without the option specified.
Reviewed as https://reviews.llvm.org/D26186
llvm-svn: 287388
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
libc++ no longer supports C++11 compilers that don't implement `= default`.
This patch removes all instances of the feature test macro
_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS as well as the potentially dead code it hides.
llvm-svn: 287321
Fix a typo in the conditional. Caught by going through list of removed
symbols when building with hidden visibility.
Differential Revision: https://reviews.llvm.org/D26825
llvm-svn: 287309
Currently sym_check almost all names found in the binary, including those
which are defined in other libraries. This makes our ABI lists harder to maintain.
This patch adds a --only-stdlib-symbols option to sym_check which removes
all symbols which aren't possibly provided by libc++. It also re-generates
the linux ABI list after making this change.
llvm-svn: 287294
This is a generalization of `_LIBCPP_NEW_DELETE_VIS`; the new macro name
captures the semantics better, and also allows us to get rid of the
`_WIN32` check in `include/new`. No functional change.
Differential Revision: https://reviews.llvm.org/D26702
llvm-svn: 287164
This fails with gcc because __builtin_isnan and friends, which
libcpp_isnan and friends call, are not themselves constexpr-evaluatable.
llvm-svn: 287041
Adding a Clang Format file to libc++ and which style it should use has been
discussed a couple of times. This patch finally adds a .clang-format file
which specifies LLVM styles.
Personally I dislike how the LLVM style handles much of the meta-programming
in libc++. However the general consensus was that libc++ should prefer the
LLVM style and make adjustments where needed.
Note that using clang-format on changes is not required, especially for
changes within the headers. However formatting tests should be encouraged.
llvm-svn: 287020
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
This patch adds a `check-cxx-abilist` target which verifies the libc++.so ABI
when the current build configuration matches the configuration used to generate
the ABI lists.
In order to make this change `HandleOutOfTreeLLVM.cmake` needed to be modified
to include `LLVMConfig.cmake` so that `TARGET_TRIPLE` is defined. Hopefully
the changes needed to accommodate this won't break existing build
configurations.
llvm-svn: 286789
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
The runtimes subdir is the new location for runtimes, we should
include it when looking for libcxxabi headers.
Differential Revision: https://reviews.llvm.org/D26363
llvm-svn: 286333
Visual Studio 2013 and up have these functions, and we don't need to
support older versions.
There are some remaining _LIBCPP_MSVCRT exclusions which are present on
Visual Studio 2015 but not 2013. Those will be addressed in a follow-up.
Differential Revision: https://reviews.llvm.org/D26377
llvm-svn: 286202
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
Create this define in __config and use it elsewhere, instead of checking
the operating system/library defines in other files. The aim is to
reduce the usage of _WIN32 outside __config. No functional change.
Differential Revision: https://reviews.llvm.org/D25741
llvm-svn: 285582
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
Adding both 'inline' and 'always_inline' to the destructor has been contentious.
However most of the performance benefits can be gained by only adding 'inline',
and there is no reason to hold up that change while discussing the other.
llvm-svn: 285538
path uses string::append to construct, append, and concatenate paths. Unfortunatly
string::append has a strong exception safety guaranteed and if it can't prove
that the iterator operations don't throw then it will allocate a temporary
string copy to append to. However this extra allocation and copy is very
undesirable for path which doesn't have the same exception guarantees.
To work around this this patch adds string::__append_forward_unsafe which exposes
the std::string::append interface for forward iterators without enforcing
that the iterator is noexcept.
llvm-svn: 285532
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
Chris Bieneman