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
It's an internal function and shouldn't be exported. It's also a source
of discrepancy in the published ABI list; these symbols aren't exported
for me on CentOS 7 or Ubuntu 16.04, leading to spurious check-cxx-abilist
failures.
Differential Revision: https://reviews.llvm.org/D27153
llvm-svn: 290503
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
This patch fixes a performance bug when constructing or appending to a path
from a string or c-string. Previously we called 'push_back' to append every
single character. This caused multiple re-allocation and copies when at most
one reallocation is necessary. The new behavior is to simply call
`string::append` so it can correctly handle reallocation.
For large strings this change is a ~4x improvement. This also makes our path
faster to construct than libstdc++'s.
llvm-svn: 285530
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
Author: laxmansole
Reviewers: howard.hinnant
mclow.lists
Subscribers: EricWF, flyingforyou, evandro
Differential Revision: https://reviews.llvm.org/D25624
Reapplying the patch as the bug https://llvm.org/bugs/show_bug.cgi?id=30341 is fixed.
Currently basic_string's destructor is not getting inlined. So adding 'inline' attribute to ~basic_string().
Worked in collaboration with Aditya Kumar.
llvm-svn: 285456
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
Summary:
This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib.
On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them.
Also could a FreeBSD maintainer comment on the ABI compatibility of this patch?
Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim
Subscribers: beanz, mgorny, cfe-commits, modocache
Differential Revision: https://reviews.llvm.org/D25593
llvm-svn: 285101
Summary:
`__libcpp_refstring` currently has two different definitions. First there is the complete definition in `<__refstring>` but there is also a second in `<stdexcept>`. The historical reason for this split is because both libc++ and libc++abi need to see the inline definitions of __libcpp_refstrings methods, but the `<stdexcept>` header doesn't. However this is an ODR violation and breaks the modules build.
This patch fixes the issue by creating a single class definition in `<stdexcept>` and changing `<__refstring>` to contain only the inline method definitions. This way both `libcxx/src/stdexcept.cpp` and `libcxxabi/src/stdexcept.cpp` see the same declaration in `<stdexcept>` and definitions in `<__refstring>`
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25603
llvm-svn: 285100
musl's pthread implementations use volatile types in their structs
which is not being constexpr in C++11 but is in C++14.
Differential Revision: https://reviews.llvm.org/D25491
llvm-svn: 284950
These modules are necessary on Darwin to allow modules with
'no_undeclared_includes' (introduced in clang r284797) to work properly
while using libc++ headers.
Patch extracted from a suggested module.modulemap from Richard Smith!
llvm-svn: 284801
Adjust the stand-alone build files to accept either CMake files from
LLVM_CMAKE_PATH or from LLVM_MAIN_SRC_DIR instead of requiring both.
This makes it possible to run libcxx tests on top of installed LLVM
and lit, without having to unpack a copy of LLVM sources. Furthermore,
it avoids adding duplicate paths.
Differential Revision: https://reviews.llvm.org/D25093
llvm-svn: 284583
Convert the Solaris xlocale.c compatibility library from plain C to C++
in order to fix the build failures caused by the addition of -std=c++11
to LIBCXX_COMPILE_FLAGS. The additional flag got propagated to the C
file, resulting in error with strict compilers.
Differential Revision: https://reviews.llvm.org/D25431
llvm-svn: 284494
Fix the iswxdigit_l() function prototype to take wint_t parameter
instead of incorrect wchar_t.
Differential Revision: https://reviews.llvm.org/D25431
llvm-svn: 284493
This fixes a small omission where even when __external_threading is provided,
we attempt to declare a pthread based threading API. Instead, we should leave
out everything for the __external_threading header to take care of.
The __threading_support header provides a proof-of-concept externally threaded
libc++ variant when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined. But if the
__external_threading header is present, we should exclude all of that POC stuff.
Reviewers: EricWF
Differential revision: https://reviews.llvm.org/D25468
llvm-svn: 284232
Libc++ will not build with modules enabled. In order to support an in-tree
libc++ when LLVM_ENABLE_MODULES is ON we need to explicitly disable the feature.
Unfortunately the libc++ sources are fundamentally non-modular. For example
iostream.cpp defines cout, cerr, wout, ... as char buffers instead of streams
in order to better control initialization/destruction. Not shockingly Clang
diagnoses this. Many other sources files define _LIBCPP_BUILDING_FOO macros to
provide definitions for normally inline symbols (See bind.cpp). Finally The
current module.map prohibits using <strstream> in C++11 so we can't build
strstream.cpp.
I think I can fix most of these issues but until then just disable modules.
llvm-svn: 284230
Summary:
This patch implements the library side of P0035R4. The implementation is thanks to @rsmith.
In addition to the C++17 implementation, the library implementation can be explicitly turned on using `-faligned-allocation` in all dialects.
Reviewers: mclow.lists, rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D25591
llvm-svn: 284206
These functions were removed from the dylib sometime between the 3.9 release
and now. This patch manually exports them to re-gain ABI compatibility.
llvm-svn: 284193
The primary reason for this patch is to add the OS X ABI lists for 3.9 and
ToT.
However while working on that I discovered that we incorrectly
exported the libc++abi symbols. Previously we had chosen the wrong CMake
configuration path and that caused us to re-export the c++abi binary instead
of using the symbol lists.
llvm-svn: 284188
Summary:
On FreeBSD, for ABI compatibility reasons, the pair trivial copy
constructor is disabled, using the aptly-named
`_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR` define.
Disable the related tests when this define is on, so they don't fail
unexpectedly.
Reviewers: emaste, rsmith, theraven, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25449
llvm-svn: 284047
The behavior of this macro actually needs to apply universally on
Windows and not just when using the Microsoft CRT. Update the macro
definition and documentation accordingly.
Differential Revision: https://reviews.llvm.org/D25145
llvm-svn: 284016
Summary:
Adapt implementation of Library Fundamentals TS optional into an implementation of N4606 optional.
- Update relational operators per http://wg21.link/P0307
- Update to requirements of http://wg21.link/P0032
- Extension: Implement trivial copy/move construction/assignment for `optional<T>` when `T` is trivially copyable.
Audit P/Rs for optional LWG issues:
- 2756 "C++ WP optional<T> should 'forward' T's implicit conversions" Implemented, which also resolves 2753 "Optional's constructors and assignments need constraints" (modulo my refusal to explicitly delete the move operations, which is a design error that I'm working on correcting in the 2756 P/R).
- 2736 "nullopt_t insufficiently constrained" Already conforming. I've added a test ensuring that `nullopt_t` is not copy-initializable from an empty braced-init-list, which I believe is the root intent of the issue, to avoid regression.
- 2740 "constexpr optional<T>::operator->" Already conforming.
- 2746 "Inconsistency between requirements for emplace between optional and variant" No P/R, but note that the author's '"suggested resolution" is already implemented.
- 2748 "swappable traits for optionals" Already conforming.
- 2753 "Optional's constructors and assignments need constraints" Implemented.
Most of the work for this patch was done by Casey Carter @ Microsoft. Thank you Casey!
Reviewers: mclow.lists, CaseyCarter, EricWF
Differential Revision: https://reviews.llvm.org/D22741
llvm-svn: 283980
This patch is largely thanks to Casey Carter @ Microsoft. He did the initial
work of porting our experimental implementation and tests over to namespace
std.
llvm-svn: 283977
Summary:
FreeBSD ships an old ABI for std::pair which requires that it have non-trivial copy/move constructors. Currently the non-trivial copy/move is achieved by providing explicit definitions of the constructors. This is problematic because it means the constructors don't SFINAE properly. In order to SFINAE copy/move constructors they have to be explicitly defaulted and hense non-trivial.
This patch attempts to provide SFINAE'ing copy/move constructors for std::pair while still making them non-trivial. It does this by adding a base class with a non-trivial copy constructor and then allowing pair's constructors to be generated by the compiler. This also allows the constructors to be constexpr.
Reviewers: emaste, theraven, rsmith, dim
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25389
llvm-svn: 283944
Fuchsia is a new operating system which uses musl as the standard
C library, libc++ and libc++abi as the C++ standard library.
Differential Revision: https://reviews.llvm.org/D25414
llvm-svn: 283788
The implementation of [depr.c.headers] in D12747 introduced the necessary
C headers into libc++. This patch adds one more missing headers: limits.h
We spotted this due to a failing C++03 test [limits_h.pass.cpp] in our libc++
configuration; when the limits.h header is included from a C++ program, it now
bypassed the __config header and went directly into the underlying C library's
limits.h header, which is problematic for us because we use __config header to
configure the underlying C library's behaviour when used from a C++ context.
Reviewers: mclow.lists, rsmith
Differential revision: https://reviews.llvm.org/D25361
llvm-svn: 283726
__builtin_addressof was added to the GCC trunk in the past week. This patch
teaches libc++ about it so it can correctly provide constexpr addressof.
Unfortunately this patch will break users of earlier GCC 7 builds, since
we expect __builtin_addressof but one won't be provided. One option would be
to only use __builtin_addressof for GCC 7.1 and above, but that means
waiting for another release.
Instead I've specifically chosen to break older GCC 7 versions. Since GCC 7
has yet to be released, and the 7.0 release is a development release, I
believe that anybody currently using GCC 7.0 will have no issue upgrading.
llvm-svn: 283715
r283659 changed the argument to gen_link_script.py from SCRIPT_ABI_LIBNAME to
LIBCXX_LIBRARIES_PUBLIC, assuming that all of the items in the
LIBCXX_LIBRARIES_PUBLIC list were library names. This is not right, however,
for in-tree libcxxabi builds, we might have the target name in this list. There
was special logic to fixup SCRIPT_ABI_LIBNAME for this situation; change it to
apply a similar fixup for LIBCXX_LIBRARIES_PUBLIC.
llvm-svn: 283684
Introduce LIBCXX_LIBRARIES_PUBLIC in addition to LIBCXX_LIBRARIES that
holds 'public' interface libraries -- that is, libraries that both
libc++ links to and programs linked against it need to link to.
Currently this includes the ABI library and optionally -lunwind (when
LIBCXXABI_USE_LLVM_UNWINDER is on). The libraries are included in the
linker script, in order to make it possible to link C++ programs using
clang with compiler-rt runtime out-of-the-box.
Differential Revision: https://reviews.llvm.org/D25008
llvm-svn: 283659
Summary:
To quote STL the problems with stack allocator are"
>"stack_allocator<T, N> is seriously nonconformant to N4582 17.6.3.5 [allocator.requirements].
> First, it lacks a rebinding constructor. (The nested "struct rebind" isn't sufficient.)
> Second, it lacks templated equality/inequality.
> Third, it completely ignores alignment.
> Finally, and most severely, the Standard forbids its existence. Allocators are forbidden from returning memory "inside themselves". This requirement is implied by the Standard's requirements for rebinding and equality. It's permitted to return memory from a separate buffer object on the stack, though."
This patch attempts to address all of those issues.
First, instead of storing the buffer inside the allocator I've change `stack_allocator` to accept the buffer as an argument.
Second, in order to fix rebinding I changed the parameter list from `<class T, size_t NumElements>` to `<class T, size_t NumBytes>`. This allows allocator rebinding
between types that have different sizes.
Third, I added copy and rebinding constructors and assignment operators.
And finally I fixed the allocation logic to always return properly aligned storage.
Reviewers: mclow.lists, howard.hinnant, STL_MSFT
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25154
llvm-svn: 283631
This was caused by r281673, specifically changing `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS`
from `__attribute__((__type_visibility__("default")))` to
`__attribute__((__visibility("default")))`.
I made that change because I thought the external instantiations needed
their members to have default visibility. However since libc++ never builds
with -fvisibility=hidden this appears not to be needed. Instead this change
caused previously hidden inline methods to become un-hidden, which is a regression.
This patch reverts the problematic change and fixes PR30642.
llvm-svn: 283620
* Fix self-swap. Patch from Casey Carter.
* Remove workarounds and tests for types with deleted move constructors. This
was originally added as part of a LWG proposed resolution that has since
changed.
* Re-apply most recent PR for LWG 2769.
* Re-apply most recent PR for LWG 2754. Specifically fix the SFINAE checks to
use the decayed type.
* Fix tests to allow moved-from std::any's to have a non-empty state. This is
the behavior of MSVC's std::any.
* Various whitespace and test fixes.
llvm-svn: 283606
First batch of changes to get some of these XFAILs working in the
no-exceptions libc++ variant.
Changed some XFAILs to UNSUPPORTED where the test is all about exception
handling. In other cases, used the test macros TEST_THROW and
TEST_HAS_NO_EXCEPTIONS to conditionally exclude those parts of the test
that concerns exception handling behaviour.
Reviewers: EricWF, mclow.lists
Differential revision: https://reviews.llvm.org/D24562
llvm-svn: 283441
Summary:
The current implementation of `hash_code()` for uniqued RTTI strings violates strict aliasing by dereferencing a type-punned pointer. Specifically it generates a `const char**` pointer from the address of the `__name` member before casting it to `const size_t*` and dereferencing it to get the hash. This is really just a complex and incorrect way of writing `reinterpret_cast<size_t>(__name)`.
This patch changes the conversion sequence so that it no longer contains UB.
Reviewers: howard.hinnant, mclow.lists
Subscribers: rjmccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D24012
llvm-svn: 283408
Summary: There's a macro scheme already being used for __has_feature etc. Use it for __has_include too, which makes MSVC happy (it doesn't support __has_include yet, and unguarded use explodes horribly).
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25251
llvm-svn: 283260
The libc-provided isnan/isinf/isfinite macro implementations are specifically
designed to function correctly, even in the presence of -ffast-math (or, more
specifically, -ffinite-math-only). As such, on most implementation, these
either always turn into external function calls (e.g. glibc) or are
specifically function calls when FINITE_MATH_ONLY is defined (e.g. Darwin).
Our implementation of complex arithmetic makes heavy use of isnan/isinf/isfinite
to deal with corner cases involving non-finite quantities. This was problematic
in two respects:
1. On systems where these are always function calls (e.g. Linux/glibc), there was a
performance penalty
2. When compiling with -ffast-math, there was a significant performance
penalty (in fact, on Darwin and systems with similar implementations, the code
may in fact be slower than not using -ffast-math, because the inline
definitions provided by libc become unavailable to prevent the checks from
being optimized out).
Eliding these inf/nan checks in -ffast-math mode is consistent with what
happens with libstdc++, and in my experience, what users expect. This is
critical to getting high-performance code when using complex<T>. This change
replaces uses of those functions on basic floating-point types with calls to
__builtin_isnan/isinf/isfinite, which Clang will always expand inline. When
using -ffast-math (or -ffinite-math-only), the optimizer will remove the checks
as expected.
Differential Revision: https://reviews.llvm.org/D18639
llvm-svn: 283051
Add underscore aliases for strtof_l and strtod_l. _strtold_l exists in
VS 2013 and above, so fix that definition as a drive-by fix.
Differential Revision: https://reviews.llvm.org/D25059
llvm-svn: 282681
Replace a stale reference to cxx_EXPORTS with _LIBCPP_BUILDING_LIBRARY,
and clarify why the operator new and delete family of functions are
marked dllexport when building but *not* dllimport when including the
header externally.
The new code is identical to the intent of the old code (and would be
functionally equivalent were cxx_EXPORTS still defined when building
libc++). The overall behavior is not ideal, since Microsoft's operator
new and delete functions will get called instead of libc++'s, but I
think consistently calling msvcrt's functions is better than either
calling msvcrt's or libc++'s functions depending on header inclusion.
Differential Revision: https://reviews.llvm.org/D25042
llvm-svn: 282644
This patch applies the _LIBCPP_SAFE_STATIC attribute to internal globals,
most of which are locking primitives, in order to ensure that they can
safely be used during program startup.
This patch also fixes an unsafe static init issue with the global locks
used to implement atomic operations on shared pointers. Previously the
locks were initialized using a dynamically initialized pointer, so it was
possible that the pointer was uninitialized.
llvm-svn: 282640
The ::stat struct on Linux, FreeBSD, and OS X provides the access and
modification times as an instance of 'timespec', which has a nanosecond
resolution. The 'st_mtime' and 'st_atime' members simply reference the 'tv_sec'
value of the timespec struct. This patch changes 'last_write_time(...)' so that
it extracts both the seconds and nanoseconds values of the last modification
time, providing a more accurate implementation of 'last_write_time(...)'.
Additionally this patch fixes a possible signed integer overflow bug. The
'file_time_type' type cannot represent all possible values returned by
the filesystem. Attempting to construct a 'file_time_type' from one of these
values is undefined behavior. This patch avoids that UB by detecting possible
overflows before the conversion.
llvm-svn: 282634
Revert r282483 as it causes build failures due to missing symbols when
not linking to -lgcc_s (i.e. doing pure LLVM stack build). The patch can
be reintroduced when the build system is fixed to add all needed
libraries (libunwind, compiler-rt).
llvm-svn: 282524
Add the "-Wl,-z,defs" linker option that is used to prevent
underlinking. It is already used by LLVM itself but does not get
propagated into stand-alone build of libc++. This patch ensures
that the option is passed in independently of whether libc++ is built
in-tree or out-of-tree.
Patch by Lei Zhang.
Differential Revision: https://reviews.llvm.org/D24119
llvm-svn: 282483
Strip the set of flags (including debug defs, -m32) that could
be inherited from top-level LLVM build only when in-tree build is
performed. This prevents libcxx from confusingly and undesiredly
stripping user-supplied flags e.g. when performing packaging system
controlled multi-ABI build.
Otherwise, in order to perform 32-bit builds the build scripts would
have to use LIBCXX_BUILD_32_BITS. However, -m32 is only one of the many
different ABI flags for different targets, and it really makes no sense
to add separate CMake options for each possible -m* flag and then keep
a mapping from well-known flags to the custom CMake options.
Differential Revision: https://reviews.llvm.org/D24809
llvm-svn: 282475
builds.
On Windows the __declspec(dllimport) and __declspec(dllexport) attributes
require linking to a DLL, not a static library. Previously these annotations
were disabled by default unless _LIBCPP_DLL was defined. However the DLL
configuration is probably the more common one, so it should be supported by
default.
This patch enables import/export attributes by default and adds a
_LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this
behavior. If libc++ is built as a static library on Windows then a custom __config
header will be generated that predefines this macro.
This patch is based off work by Shoaib Meenai.
llvm-svn: 282449
Summary: This patch fixes a couple of typos that cause compilation errors when application includes <unordered_map> and enables the libc++'s debugging capabilities.
Reviewers: EricWF
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D24883
llvm-svn: 282446
Summary:
`std::move` and `std::forward` were not marked constexpr in C++11. This can be very damaging because it makes otherwise constant expressions non-constant. For example:
```
#include <utility>
template <class T>
struct Foo {
constexpr Foo(T&& tx) : t(std::move(tx)) {}
T t;
};
[[clang::require_constant_initialization]] Foo<int> f(42); // Foo should be constant initialized but C++11 move is not constexpr. As a result `f` is an unsafe global.
```
This patch applies `constexpr` to `move` and `forward` as an extension in C++11. Normally the library is not allowed to add `constexpr` because it may be observable to the user. In particular adding constexpr may cause valid code to stop compiling. However these problems only happen in more complex situations, like making `__invoke(...)` constexpr. `forward` and `move` are simply enough that applying `constexpr` is safe.
Note that libstdc++ has offered this extension since at least 4.8.1.
Most of the changes in this patch are simply test cleanups or additions. The main changes in the tests are:
* Fold all `forward_N.fail.cpp` tests into a single `forward.fail.cpp` test using -verify.
* Delete most `move_only_N.fail.cpp` tests because they weren't actually testing anything.
* Fold `move_copy.pass.cpp` and `move_only.pass.cpp` into a single `move.pass.cpp` test.
* Add return type and noexcept tests for `forward` and `move`.
Reviewers: rsmith, mclow.lists, EricWF
Subscribers: K-ballo, loladiro
Differential Revision: https://reviews.llvm.org/D24637
llvm-svn: 282439
Declare __STDC_FORMAT_MACROS, __STDC_LIMIT_MACROS and
__STDC_CONSTANT_MACROS before including real inttypes.h/stdint.h when
the wrapper-header is included in C++11, in order to enable
the necessary macros in C99-compliant libc.
The C99 standard defined that the format macros in inttypes.h should be
defined by the C++ implementations only when __STDC_FORMAT_MACROS is
defined, and the limit and constant macros in stdint.h should be defined
only when __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS are defined
appropriately. Following this specification, multiple old versions of
glibc up to 2.17 do not define those macros by default for C++,
rendering the libc++ headers non-compliant to the C++11 standard.
In order to achieve the necessary compliance, __STDC_FORMAT_MACROS is
defined in wrapped inttypes.h just before including the system
inttypes.h, when C++11 or newer is used. Both __STDC_LIMIT_MACROS
and __STDC_CONSTANT_MACROS are defined in newly-wrapped stdint.h. This
fixes the C++11 compliance while preserving the current behavior for
C++03.
Differential Revision: https://reviews.llvm.org/D24903
llvm-svn: 282435
Summary:
Libc++ still uses per-feature configuration macros when configuring for C++11. However libc++ requires a feature-complete C++11 compiler so there is no reason to check individual features. This patch starts the process of removing the feature specific macros and replacing their usage with `_LIBCPP_CXX03_LANG`.
This patch removes the __config macros:
* _LIBCPP_HAS_NO_TRAILING_RETURN
* _LIBCPP_HAS_NO_TEMPLATE_ALIASES
* _LIBCPP_HAS_NO_ADVANCED_SFINAE
* _LIBCPP_HAS_NO_DEFAULT_FUNCTION_TEMPLATE_ARGS
* _LIBCPP_HAS_NO_STATIC_ASSERT
As a drive I also changed our C++03 static_assert to use _Static_assert if available.
I plan to commit this without review if nobody voices an objection.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24895
llvm-svn: 282347
Summary:
This patch has been a long time coming (Thanks @eugenis). It changes `_LIBCPP_INLINE_VISIBILITY` to use `__attribute__((internal_linkage))` instead of `__attribute__((visibility("hidden"), always_inline))`.
The point of `_LIBCPP_INLINE_VISIBILITY` is to prevent inline functions from being exported from both the libc++ library and from user libraries. This helps libc++ better manage it's ABI.
Previously this was done by forcing inlining and modifying the symbols visibility. However inlining isn't guaranteed and symbol visibility only affects shared libraries making this an imperfect solution. `internal_linkage` improves this situation by making all symbols local to the TU they are emitted in, regardless of inlining or visibility. IIRC the effect of applying `__attribute__((internal_linkage))` to an inline function is the same as applying `static`.
For more information about the attribute see: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
Most of the work for this patch was done by @eugenis.
Reviewers: mclow.lists, eugenis
Subscribers: eugenis, cfe-commits
Differential Revision: https://reviews.llvm.org/D24642
llvm-svn: 282345
Visual Studio 2013 and onward have all the required functions in their
CRT headers, and we don't support older versions anymore.
Differential Revision: https://reviews.llvm.org/D24879
llvm-svn: 282328
On Windows, marking an `extern template class` declaration as exported
actually forces an instantiation, which is not the desired behavior.
Instead, the actual explicit instantiations need to be exported.
Differential Revision: https://reviews.llvm.org/D24679
llvm-svn: 281925
Summary:
None of these checks are specific to Android devices. If libc++ was
used with Bionic on a normal Linux system these checks would still be
needed.
Reviewers: mclow.lists, EricWF
Subscribers: compnerd, tberghammer, danalbert, srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D24690
llvm-svn: 281921
gcc and clang in gcc compatibility mode do not accept __forceinline. Use
the gcc attribute for them instead.
Differential Revision: https://reviews.llvm.org/D24678
llvm-svn: 281766
The externally instantiated member functions must be declared using
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY, not _LIBCPP_INLINE_VISIBILITY, in
order to be properly exported when using __attribute__((internal_linkage)).
Otherwise the explicit instantiations will obviously have internal linkage and
will not be exported from the dylib.
llvm-svn: 281684
Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!
This patch adds two new visibility macros:
* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.
After applying this patch GCC only emits one -Wattribute warning opposed to 30+.
Reviewers: mclow.lists, EricWF
Subscribers: beanz, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D24602
llvm-svn: 281673
When `_LIBCPP_NO_EXCEPTIONS` is defined, we end up with compile errors
when targeting MSVCRT:
* Code includes `<new>`
* `<new>` includes `<cstdlib>` in order to get `abort`
* `<cstdlib>` includes `<stdlib.h>`, _before_ the `using ::abort`
* `<stdlib.h>` includes `locale_win32.h`
* `locale_win32.h` includes `<memory>`
* `<memory>` includes `<stdexcept>`
* `<stdexcept>` includes `<cstdlib` for `abort`, but that inclusion gets
(correctly) ignored because of header guards
* `<stdexcept>` references `_VSTD::abort`, which isn't declared
The easiest solution is to make `locale_win32.h` not include `<memory>`,
by removing the use of `unique_ptr` and manually restoring the locale
instead.
Differential Revision: https://reviews.llvm.org/D24374
llvm-svn: 281641
This patch causes a couple of issues:
1) It triggers http://llvm.org/PR30341. Although the bug is not truly a libc++
bug it breaks the LLVM build using libc++. Reverting this patch is only
a temporary workaround until Clang is fixed.
2) It adds yet another ABI incompatibility when libc++.so is compiled with GCC.
Specifically GCC doesn't ignore the _LIBCPP_INLINE_VISIBILITY on the out-of-line
definition when compiling the dylib. This causes the externally instantiated
~basic_string symbol to have hidden visibility.
This patch should be recommitted after addressing (1) and (2). (2) can be fixed
by adding _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY which is defined as
__attribute__((visibility("default"), always_inline)) as opposed to
_LIBCPP_INLINE_VISIBILITY which makes the symbol hidden.
llvm-svn: 281562
This patch enables building and testing libcxx under ThreadSanitizer on OS X. CMake builds that have -DLLVM_USE_SANITIZER=Thread will automatically build libcxx with -fsanitize=thread and testing via lit then runs under TSan.
Differential Revision: https://reviews.llvm.org/D24297
llvm-svn: 281475
An enum class has associated type info. In the Microsoft ABI, type info
is emitted in the COMDAT section and isn't exported, so clang rightfully
complains about __declspec(dllexport) being unused for an enum class.
On other platforms, we still want to export the type info.
Differential Revision: https://reviews.llvm.org/D24065
llvm-svn: 281264
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
Visual Studio 2013 (CRT version 12) added support for many C99 long long and
long double functions. Visual Studio 2015 (CRT version 14) increased C99 and C11
compliance further. Since we don't support Visual Studio versions older than
2013, we can considerably clean up the support header.
Patch by Shoaib Meenai!
llvm-svn: 280988
Author: laxmansole
Reviewers: howard.hinnant
mclow.lists
Subscribers: EricWF, flyingforyou, evandro
Differential Revision: https://reviews.llvm.org/D22834
Currently basic_string's destructor is not getting inlined. So adding 'inline' attribute to ~basic_string().
Worked in collaboration with Aditya Kumar.
llvm-svn: 280944
This patch fixes PR30260 by using a (void*) cast on the placement argument
to placement new to casts away the const. See also http://llvm.org/PR30260.
As a drive by change this patch also changes the header guard for
<experimental/optional> to _LIBCPP_EXPERIMENTAL_OPTIONAL from _LIBCPP_OPTIONAL.
llvm-svn: 280775
When libc++experimental was originally created it was empty and therefore there
was no reason to install it. Now that the library contains
<experimental/memory_resource> and <experimental/filesystem> there is a good
reason to install it.
Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY
is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true.
llvm-svn: 280773
This patch removes the `<cstdlib>` include from exception where it is no longer
needed. Unlike my previous attempt this patch also adds <cstdlib> where needed
in other headers like <new> and <typeinfo>.
This won't fix the Firefox build issues discussed on IRC but it is more correct
for libc++.
llvm-svn: 280754
Apparently I missed a number of additional include which need to be added.
Reverting so I can recommit as a single patch with all of the required includes.
llvm-svn: 280752
call_once is using relaxed atomic load to perform double-checked locking, which contains a data race. The fast-path load has to be an acquire atomic load.
Differential Revision: https://reviews.llvm.org/D24028
llvm-svn: 280621
Summary:
This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`.
Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec:
>
> Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread.
>
> An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.
>
> If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop.
However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit".
Reviewers: mclow.lists, bcraig, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24159
llvm-svn: 280588
When <bitset> is compiled with warnings enabled, on a platform where
size_t is 4 bytes, it results in errors similar to:
bitset:265:16: error: non-constant-expression cannot be narrowed
from type 'unsigned long long' to '__storage_type' (aka 'unsigned
int') in initializer list [-Wc++11-narrowing]
: __first_{__v, __v >> __bits_per_word}
^~~
bitset:676:52: note: in instantiation of member function
'std::__1::__bitset<2, 53>::__bitset' requested here
bitset(unsigned long long __v) _NOEXCEPT : base(__v) {}
^
Fix these by casting the initializer list elements to __storage_type.
Reviewers: mclow.lists, EricWF
Differential Revision: https://reviews.llvm.org/D23960
llvm-svn: 280543
Microsoft removed gets from the CRT in Visual Studio 2015 onwards [1].
Attempting to reference it when targeting CRT versions 14 and above will cause
compile errors.
[1] https://msdn.microsoft.com/en-us/library/2029ea5f.aspx
Patch by Shoaib Meenai!
llvm-svn: 280417
`-fPIC` doesn't make much sense for Windows, since Windows DLLs aren't compiled
position independent and are instead relocated at runtime.
Patch by Shoaib Meenai!
llvm-svn: 280413
In r280108 I tried to make the headers copy relative to LLVM_BINARY_DIR, and the intent was that it would only happen on in-tree builds or runtimes directory builds. It didn't actually work that way.
This patch adds a check for CMAKE_SOURCE_DIR being equal to CMAKE_CURRENT_SOURCE_DIR. In this case we set a variable LIBCXX_USING_INSTLLED_LLVM. This doesn't necessarily mean the LLVM is installed (it could be a build directory), but it means we need to treat the LLVM directory as read-only.
llvm-svn: 280400
Summary: This copy phase is only needed for in-tree builds, so we should be copying to the LLVM build directory's include dir instead of the sub-project include dir.
Reviewers: bogner, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24015
llvm-svn: 280108
Some of the mutex tests fail on machines with high load. This patch implements
the test directive "// FLAKY_TEST" which allows a test to be run 3 times
before it's considered a failure.
llvm-svn: 280050
We're compiling libc++ with -nodefaultlibs, so we should also pass this
option during the configuration checks to ensure those checks are
consistent with the actual build.
The primary motivation here is to ease cross-compilation against a
non-standard set of C++ libraries. Previously, the configuration checks
would attempt to link against the standard C++ libraries, which would
cause link failures when cross-compiling, even though the actual library
link would go through correctly (because of the use of -nodefaultlibs
and explicitly specifying any needed libraries). This is more correct
even ignoring the motivation, however.
Patch by Shoaib Meenai!
llvm-svn: 280015
Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:
* Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed.
* Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized.
* Fix -Wunused-value warning in `__all` by adding a void cast.
* Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy.
* Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning.
* Ignore -Wc++14-compat since it warns about the sized new/delete overloads.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D24003
llvm-svn: 280007
This patch enables the `cxx-benchmarks` target by default. Note that the target
still has to be manually invoked since it isn't included in the default 'make'
rule.
This patch also gets the benchmarks building w/ GCC. The build previously
required the '-stdlib=libc++' flag but upstream patches to Google Benchmark
now allow the library to build w/ libc++ and GCC.
These changes should make the benchmarks easier to build and test.
llvm-svn: 279999
This assignment operator was previously broken since the SFINAE always resulted
in substitution failure. This caused assignments to turn into
copy construction + assignment.
This patch was originally committed as r279953 but was reverted due to warnings
in the test-suite. This new patch corrects those warnings.
llvm-svn: 279955
This assignment operator was previously broken since the SFINAE always resulted
in substitution failure. This caused assignments to turn into
copy construction + assignment.
llvm-svn: 279953
This patch implements the std::sample function added to C++17 from LFTS. It
also removes the std::experimental::sample implementation which now forwards
to std::sample.
llvm-svn: 279948
Libc++'s implementation of shuffle and sample already support lvalue and rvalue
RNG's. This patch adds tests for both categories and marks the issue as complete.
This patch also contains drive-by change for std::experimental::sample which
improves the diagnostics produced when the correct iterator categories are
not supplied.
llvm-svn: 279947
Similar to rL242623, move C++ version checks outside of _NOEXCEPT_()
macro invocation argument lists, to avoid "embedding a directive within
macro arguments has undefined behavior" warnings.
Differential Revision: https://reviews.llvm.org/D23961
llvm-svn: 279926
Summary:
The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name.
This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23699
llvm-svn: 279675
We're compiling libc++ with -nodefaultlibs, so we should also pass this option
during the configuration checks to ensure those checks are consistent with the
actual build.
The primary motivation here is to ease cross-compilation against a non-standard
set of C++ libraries. Previously, the configuration checks would attempt to link
against the standard C++ libraries, which would cause link failures when
cross-compiling, even though the actual library link would go through correctly
(because of the use of -nodefaultlibs and explicitly specifying any needed
libraries). This is more correct even ignoring the motivation, however.
Patch by Shoaib Meenai!
llvm-svn: 279584
Some tests uses 'long double' to/from conversions and for some targets
they are provided by compiler runtime (either compiler-rt or libgcc).
However when building libcxx with linunwinder current test configuration
at target_info.py do not include the required libraries, as:
not llvm_unwinder:
"-lc++" "-lm" "-lgcc_s" "-lgcc" "-lpthread" "-lc" "-lgcc_s" "-lgcc"
llvm_unwinder
"-lc++" "-lm" "-lpthread" "-lc" "-lunwind" "-ldl"
This causes some tests build issues with missing symbols on aarch64,
for instance, where 'long double' is a binary float with 128-bits with
mostly of internal operations being provided by software routines.
This patch changes how to define the default linker flags with libunwinder by
adding libgcc regardless.
I checked and aarch64 and x86_64 with libcxx and libunwind (with and without
LIBCXXABI_USE_LLVM_UNWINDER).
llvm-svn: 279552
Summary:
The new LLVM runtimes build directory requires some basic conventions across the runtime projects. These changes make libcxx build under the runtimes subdirectory. The general idea of the changes is that the runtimes subdirectory requires some conventions to be consistent across runtime projects.
I expect to have a few more small patches that build on this to tie up check targets and other things useful in development workflows.
Summary of changes in this patch:
* Renamed variable LLVM_CONFIG -> LLVM_CONFIG_PATH
* Renamed variable LIBCXX_BUILT_STANDALONE -> LIBCXX_STANDALONE_BUILD
* Add an include of AddLLVM in the tests subdirectory for add_lit_testsuite.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23696
llvm-svn: 279151
The expected 'filesystem::path::compare' result states that for different
path only result sign contains the information about passed arguments
(not its integer value). This is due it uses the output of other compare
functions (basic_string_view and char_traits) without further handling and
char_traits uses memcmp for final buffer comparison.
However for GLIBC on AArch64 the code:
int ret = memcmp ("b/a/c", "a/b/c", 1);
Results in '64' where for x86_64 it results in '1'.
This patch fixes the expected 'filesystem::path::compare' by normalizing
all the results before assert comparison.
llvm-svn: 278745
Currently certain tests get killed when compiled with ASAN at -O0 because
they eat all of the systems memory. This doesn't happen at -O1, so enable that
to work around the issue.
llvm-svn: 278722
Although libc++ only requires C++11 to build, there are other
reasons to turn on a newer dialect in the build. For example
IDE's may not highlight any C++14/C++17 in the headers when
configured for C++11. This patch add's a private option for
changing this.
llvm-svn: 278638
Some filesystems track atime always. This relaxes the test to accept either a
filesystem which does not accurately track atime or does track the atime
accurately. This allows the test to pass on filesystems mounted with
`strictatime` on Linux or on macOS.
llvm-svn: 278357
basic_string's constructor calls init which was not getting inlined. This
prevented optimization of const string as init would appear as a call in between
a string's def and use.
Patch by Laxman Sole and Aditya Kumar.
Differential Revision: https://reviews.llvm.org/D22782
llvm-svn: 278356
I've put some work into the Google Benchmark library in order to make it easier
to benchmark libc++. These changes have already been upstreamed into
Google Benchmark and this patch applies the changes to the in-tree version.
The main improvement in the addition of a 'compare_bench.py' script which
makes it very easy to compare benchmarks. For example to compare the native
STL to libc++ you would run:
`$ compare_bench.py ./util_smartptr.native.out ./util_smartptr.libcxx.out`
And the output would look like:
RUNNING: ./util_smartptr.native.out
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_SharedPtrCreateDestroy 62 ns 62 ns 10937500
BM_SharedPtrIncDecRef 31 ns 31 ns 23972603
BM_WeakPtrIncDecRef 28 ns 28 ns 23648649
RUNNING: ./util_smartptr.libcxx.out
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_SharedPtrCreateDestroy 46 ns 46 ns 14957265
BM_SharedPtrIncDecRef 31 ns 31 ns 22435897
BM_WeakPtrIncDecRef 34 ns 34 ns 21084337
Comparing ./util_smartptr.native.out to ./util_smartptr.libcxx.out
Benchmark Time CPU
-----------------------------------------------------
BM_SharedPtrCreateDestroy -0.26 -0.26
BM_SharedPtrIncDecRef +0.00 +0.00
BM_WeakPtrIncDecRef +0.21 +0.21
llvm-svn: 278147
Neither of these results files has been update in years. Linux now has a dozen
or so buildbots tracking it and the Windows results are no longer relevant.
I plan on looking into getting a Windows buildbot going using Appveyor in the
coming days.
llvm-svn: 278087
This change allows building both shared and static version of libc++
in a single build, sharing object files between both versions.
Differential Revision: https://reviews.llvm.org/D23232
llvm-svn: 278068
Summary:
The synopsis in C++11 subclause 28.8 [re.regex] has:
```
basic_regex(const charT* p, size_t len,
flag_type f = regex_constants::ECMAScript);
```
The default argument is added to libc++ by this change.
Reviewers: mclow.lists, rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22702
Reapplies r277966.
Patch by Jason Liu!
llvm-svn: 277968
Summary:
In the synopsis in C++11 subclause 28.8 [re.regex], `basic_regex` is
specified to have member typedefs `traits_type` and `string_type`. This
change adds them to libc++.
Reviewers: mclow.lists, rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22698
Patch by Jason Liu!
llvm-svn: 277526
It currently fails because GCC changed the mangling of templates, which affects std::atomic using __attribute__((vector(X))). The bot using GCC 4.9 generates the following message:
In file included from /home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/test/libcxx/atomics/atomics.align/align.pass.sh.cpp:24:0:
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic: In instantiation of 'atomic_test<T>::atomic_test() [with T = __vector(2) int]':
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/test/libcxx/atomics/atomics.align/align.pass.sh.cpp:66:3: required from here
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: error: 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' conflicts with a previous declaration
__gcc_atomic_t() _NOEXCEPT = default;
^
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: previous declaration 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(1) int]'
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: -fabi-version=6 (or =0) avoids this error with a change in mangling
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: error: 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' conflicts with a previous declaration
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: previous declaration 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(1) int]'
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:583:5: note: -fabi-version=6 (or =0) avoids this error with a change in mangling
/home/llvm-builder/llvm-buildslave-root/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11/llvm/projects/libcxx/include/atomic:939:5: note: synthesized method 'std::__1::__gcc_atomic::__gcc_atomic_t<_Tp>::__gcc_atomic_t() [with _Tp = __vector(2) int]' first required here
__atomic_base() _NOEXCEPT = default;
^
GCC's docs say the following about ABI version 6:
Version 6, which first appeared in G++ 4.7, corrects the promotion behavior of C++11 scoped enums and the mangling of template argument packs, const/static_cast, prefix ++ and –, and a class scope function used as a template argument.
llvm-svn: 277380
Summary:
libc++ implements std::atomic<_Tp> using __atomic_base<_Tp> with
`mutable _Atomic(_Tp) __a_`. That member must be suitably aligned on
relevant ISAs for instructions such as cmpxchg to work properly, but
this alignment isn't checked anywhere. __atomic_base's implementation
relies on _Atomic doing "the right thing" since it's under the
compiler's control, and only the compiler knows about lock-freedom and
instruction generation. This test makes sure that the compiler isn't
breaking libc++'s expectations.
I'm looking at a few odd things in the C++ standard, and will have a few
other fixes around this area in the future.
This requires building with `-DLIBCXX_HAS_ATOMIC_LIB=True`, the test
marks the dependency as REQUIRES and won't be run without.
Reviewers: cfe-commits
Subscribers: EricWF, mclow.lists
Differential Revision: http://reviews.llvm.org/D22073
llvm-svn: 277368
If the last destruction is uncontended, skip the atomic store on
__shared_weak_owners_. This shifts some costs from normal
shared_ptr usage to weak_ptr uses.
https://reviews.llvm.org/D22470
llvm-svn: 277357
This is a breaking change. The SFINAE required is instantiated the second
the class is instantiated, and this can cause hard SFINAE errors
when applied to references to incomplete types. Ex.
struct IncompleteType;
extern IncompleteType it;
std::tuple<IncompleteType&> t(it); // SFINAE will blow up.
llvm-svn: 276598
In C++03 mode evaluating the SFINAE can cause a hard error due to
access control violations. This is a problem because the SFINAE
is evaluated as soon as the class is instantiated, and not later.
llvm-svn: 276594
Summary:
This patch attempts to fix the undefined behavior in __hash_table by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__hash_table` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 2 node types in __hash_table:
* `__hash_node_base` which contains the `__next_` pointer.
* `__hash_node` which contains `__hash_` and `__value_`.
Currently the bucket list, iterators, and `__next_` pointers store pointers to `__hash_node` even though they all need to store `__hash_node_base` pointers.
This patch makes that change by introducing a `__next_pointer` typedef which is a pointer to `__hash_node` in the current ABI and `__hash_node_base` afterwards.
One notable change is to the type of `__bucket_list` which used to be defined as `unique_ptr<__node_pointer[], ...>` and is now `unique_ptr<__next_pointer[], ...>` meaning that we now allocate and deallocate different types using a different allocator. I'm going to give this part of the change more thought since it may introduce compatibility issues.
This change is similar to D20786.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D20787
llvm-svn: 276533
There is a bug in Clang 3.6 and earlier that causes compile failures.
I suspect it's due to the usage of member function parameter names in the
attributes.
llvm-svn: 276507
Summary:
This patch uses the __attribute__((enable_if)) hack suggested by @rsmith to diagnose invalid arguments when possible.
In order to diagnose an invalid argument `m` to `f(m)` we provide an additional overload of `f` that is only enabled when `m` is invalid. When that function is enabled it uses __attribute__((unavailable)) to produce a diagnostic message.
Reviewers: mclow.lists, rsmith, jfb, EricWF
Subscribers: bcraig, jfb, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22557
llvm-svn: 276506
Increasingly the .fail.cpp tests are written using -verify, making them
sensitive to the exact diagnostics generated by the compiler. To prevent
additional diagnostics from being generated, and causing the tests to fail,
this patch removes the warning flags when compiling those tests.
llvm-svn: 276208
Although inheriting constructors have already been fixed in Clang 3.9 I still
choose to fix std::function so users can derive from it with older compilers.
llvm-svn: 276090
The previous implementation relied highly on specializations to handle
special cases. This new implementation lets the compiler do the work when possible.
llvm-svn: 276084
Libc++ provides static assertions to detect reference binding issues inside
tuple. This patch adds tests for those diagnostics.
It should be noted that these static assertions technically violate the
standard since it allows these illegal bindings to occur.
Also see https://llvm.org/bugs/show_bug.cgi?id=20855
llvm-svn: 276078
The functions arg, conj, imag, norm, proj, and real have additional overloads
for arguments of integral or floating point types. However these overloads should
not allow conversions to the integral/floating point types, only exact matches.
This patch constrains these functions so they no longer allow conversions.
llvm-svn: 276067
Summary:
This patch does the following:
1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`.
2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL.
3. Allows performance benchmarks to be built as part of the libc++ build.
Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target.
On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries.
Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions.
Known Issues:
* `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark.
Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs
Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel
Differential Revision: https://reviews.llvm.org/D22240
llvm-svn: 276049
Summary:
This patch attempts to fix the undefined behavior in __tree by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__tree` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 3 node types in __tree.
* `__tree_end_node` which contains the `__left_` pointer. This node is embedded within the container.
* `__tree_node_base` which contains `__right_`, `__parent_` and `__is_black`. This node is used throughout the tree rebalancing algorithms.
* `__tree_node` which contains `__value_`.
Currently `__tree` stores the start of the tree, `__begin_node_`, as a pointer to a `__tree_node`. Additionally the iterators store their position as a pointer to a `__tree_node`. In both of these cases the pointee can be the end node. This is fixed by changing them to store `__tree_end_node` pointers instead.
To make this change I introduced an `__iter_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node` in the current one.
Both `__tree::__begin_node_` and iterator pointers are now stored as `__iter_pointers`.
The other situation where `__tree_end_node` is stored as the wrong type is in `__tree_node_base::__parent_`. Currently `__left_`, `__right_`, and `__parent_` are all `__tree_node_base` pointers. Since the end node will only be stored in `__parent_` the fix is to change `__parent_` to be a pointer to `__tree_end_node`.
To make this change I introduced a `__parent_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node_base` in the current one.
Note that in the new ABI `__iter_pointer` and `__parent_pointer` are the same type (but not in the old one). The confusion between these two types is unfortunate but it was the best solution I could come up with that maintains the ABI.
The typedef changes force a ton of explicit type casts to correct pointer types and to make current code compatible with both the old and new pointer typedefs. This is the bulk of the change and it's really messy. Unfortunately I don't know how to avoid it.
Please let me know what you think.
Reviewers: howard.hinnant, mclow.lists
Subscribers: howard.hinnant, bbannier, cfe-commits
Differential Revision: https://reviews.llvm.org/D20786
llvm-svn: 276003
Constructing a std::locale object from an empty string selects the language
from the current environment variables. If the environment variables name
a locale that doesn't exist, or isn't installed, then the construction of
facets using that locale may throw.
This patch removes tests that use 'std::locale l("")'.
The optimal solution would be to manually set the environment variables
in the test. Unfortunately there is no portable way to do this.
llvm-svn: 275772
man page for mkdir says: "If the parent directory has the set-group-ID bit set,
then so will the newly created directory."
Differential Revision: https://reviews.llvm.org/D22265
llvm-svn: 275760
This patch updates the way libc++ handles checking for libatomic, in part
to prepare for https://reviews.llvm.org/D22073.
Changes:
* 'LIBCXX_HAS_ATOMIC_LIB' is now set whenever libatomic is available even libc++
doesn't need to manually link it.
* 'LIBCXX_HAVE_CXX_ATOMICS_WITH_LIB' is now used to detect when libatomic
needs to be manually linked.
* 'LIBCXX_HAS_ATOMIC_LIB' now adds 'libatomic' as a available feature in the
test suite.
llvm-svn: 275759
This patch does the following:
* It renames `_LIBCPP_TRIVIAL_PAIR_COPY_CTOR` to `_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR`.
* It automatically enables this option on FreeBSD in ABI V1, since that's the current ABI FreeBSD ships.
* It cleans up the handling of this option in `std::pair`.
I would like the sign off from the FreeBSD maintainers. They will no longer need to keep their `__config` changes downstream.
I'm still hoping to come up with a better way to maintain the ABI without needing these constructors.
Reviewed in https://reviews.llvm.org/D21329
llvm-svn: 275749
This patch upgrades <tuple> to be C++17 compliant by implementing:
* tuple_size_v: This was forgotten when implementing the other _v traits.
* std::apply: This was added via LFTS v1 in p0220r1.
* std::make_from_tuple: This was added in p0209r2.
llvm-svn: 275745
This patch implements a simple optimization in __hash_table::find. When iterating
the found bucket we only constrain the bucket elements hash if it doesn't
already match the unconstrained hash of the specified key. This prevent
the performance of an expensive modulo operation.
Since the bucket element almost always matches the key, especially when the
load factor is low, this optimization has large performance impacts. For
a unordered_set<int> of random integers this patch improves the performance of
'find(...)' by 40%.
llvm-svn: 275734
From r229162:
Visual Studio's SAL extension uses a macro named __deallocate. This
macro is used pervasively
Using -Werror when building for Windows can force the use of -Wno-#warnings
specifically because of this __deallocate #warning. Instead of forcing
builds to disable all #warnings, this option allows libc++ to be built
without this particular warning, while leaving other #warnings enabled.
Patch by Dave Lee!
llvm-svn: 275172
This cleans up a previous optimization attempt in hash, and results in
additional performance improvements over that previous attempt. Additionally
this new optimization does not hinder the power of 2 bucket count optimization.
llvm-svn: 275114
Summary: The current implementations of __hash_table::find used by std::unordered_set/unordered_map call key_eq on each key that lands in the same bucket as the key you're looking for. However, since equal objects mush hash to the same value, you can short-circuit the possibly expensive call to key_eq by checking the hashes first.
Reviewers: EricWF
Subscribers: kmensah, cfe-commits
Differential Revision: http://reviews.llvm.org/D21510
llvm-svn: 274857
This patch improves the performance of unordered_set's find by 45% when
the value exists within the set. __hash_tables find method
needs to check if it's reached the end of the bucket by constraining the
hash of the current node and checking it against the bucket index. However
constraining the hash is an expensive operations and it can be avoided if the
two unconstrained hashes are equal. This patch applies that optimization.
This patch also adds a top level directory called benchmarks. 'benchmarks/'
is intended to store any/all benchmarks written for the standard library.
Currently nothing is done with files under 'benchmarks/' but I would like
to move towards introducing a formal format and test runner.
llvm-svn: 274423
This patch is the last in a series that replaces recursive meta-programming
in std::tuple with non-recursive implementations.
Previously std::tuple could only be instantiated with 126 elements before
it blew the max template instantiation depth. Now the size of std::tuple is
essentially unbounded (I've tested with over 5000 elements).
One unfortunate side-effect of this change is that tuple_constructible
and similar no longer short circuit after the first failure. Instead they
evaluate the conditions for all elements. This could be potentially breaking.
I plan to look into this further.
llvm-svn: 274331
This patch attempts to improve the QoI of std::tuples tuple_element and
__make_tuple_types helpers. Previously they required O(N) instantiations,
one for every element in the tuple
The new implementations are O(1) after __tuple_indices<Id...> is created.
llvm-svn: 274330
The previous __make_tuple_indices implementation caused O(N) instantiations
and was pretty inefficient. The C++14 __make_integer_sequence implementation
is much better, since it either uses a builtin to generate the sequence or
a very nice Log8(N) implementation provided by richard smith.
This patch moves the __make_integer_sequence implementation into __tuple
and uses it to implement __make_tuple_indices.
Since libc++ can't expose the name 'integer_sequence' in C++11 this patch
also introduces a dummy type '__integer_sequence' which is used when generating
the sequence. One the sequence is generated '__integer_sequence' can be
converted into the required type; either '__tuple_indices' or 'integer_sequence'.
llvm-svn: 274286
* P0163r0: Implemented in r273839.
* LWG 2309: pthread_mutex_lock only returns this error if certain debug flags
were passed during construction. libc++ does not pass these flags. There is
nothing to do.
* LWG 2310: Wording fix. No impact on libc++'s implementation.
* LWG 2312: libc++'s std::tuple implementation already constrains the overloads
based on the number of arguments.
* LWG 2549: libc++'s std::tuple already applied this fix.
* LWG 2674: libc++ already depends on this relaxed wording.
* LWG 2704, 2706, 2707, 2719, 2720, 2721, 2723, 2725, 2728: All of these filesystem were either
submitted by me and fixed before submission, or have already been applied.
llvm-svn: 274214
Since at least the C++11 standard insert iterators are specified
as having ::reference typedef void. Libc++ was not doing that.
This patch corrects the typedef.
This patch changes the std::iterator base class of insert_iterator,
front_insert_iterator and back_insert_iterator. This should not
be an ABI breaking change.
llvm-svn: 274209
The end pointer should point to one past the end of the newly allocated
buffer.
rdar://problem/24265174
Differential Revision: http://reviews.llvm.org/D20334
llvm-svn: 274132
This patch adds the weak_type typedef in shared_ptr. It is available in
C++17 and newer.
This patch also updates the _LIBCPP_STD_VER and TEST_STD_VER macros to
have the value of 16, since 2016 is the current year.
llvm-svn: 273839
See https://llvm.org/bugs/show_bug.cgi?id=27115
The problem was that the conversion from
'const enable_shared_from_this<T>*' to 'const T*' didn't work if
T inherited enable_shared_from_this as a virtual base class. The fix
is to take the original pointer passed to shared_ptr's constructor in the
__enable_weak_this method and perform an upcast to 'const T*' instead of
performing a downcast from the enable_shared_from_this base.
llvm-svn: 273835
The move constructor for wstring_convert accidentally copied the state member
into the converted count member in the move constructor. This patch fixes
the typo.
While working on this I discovered that wstring_convert doesn't actually
provide a move constructor according to the standard and therefore this
constructor is a libc++ extension. I'll look further into whether libc++ should
provide this constructor at all. Neither libstdc++ or MSVC's STL provide it.
llvm-svn: 273831
This patch makes the bind placeholders in std::placeholders both (1) const and
(2) constexpr (See below).
This is technically a breaking change for any code using the placeholders
outside of std::bind and depending on them being non-const. However I don't
think this will break any real world code.
(1) Previously the placeholders were non-const extern globals in all
dialects. This patch changes these extern globals to be const in all dialects.
Since the cv-qualifiers don't participate in name mangling for globals this
is an ABI compatible change.
(2) Make the placeholders constexpr in C++11 and beyond. Although LWG 2488 only
applies to C++17 I don't see any reason not to backport this change.
llvm-svn: 273824
Summary: this fixes build error when built with c++14 and no exceptions
Reviewers: rmaprath
Subscribers: weimingz, grandinj, rmaprath, cfe-commits
Differential Revision: http://reviews.llvm.org/D21673
llvm-svn: 273697
So the macros TEST_HAS_NO_EXCEPTIONS and TEST_HAS_NO_RTTI were always
getting defined because I spelt __cpp_exceptions and __cpp_rtti as
__cxx_exceptions and __cxx_rtti.
Tests incoming after this patch.
llvm-svn: 273381
Libc++ has to deduce the 'allocator_arg_t' parameter as 'AllocArgT' for the
following constructor:
template <class Alloc> tuple(allocator_arg_t, Alloc const&)
Previously libc++ has tried to support tags derived from 'allocator_arg_t' by
using 'is_base_of<AllocArgT, allocator_arg_t>'. However this breaks whenever a
2-tuple contains a reference to an incomplete type as its first parameter.
See https://llvm.org/bugs/show_bug.cgi?id=27684
llvm-svn: 273334
This changes how filesystem::permissions(p, perms) handles symlinks. Previously
symlinks were not resolved by default instead only getting resolved when
"perms::resolve_symlinks" was used. After this change symlinks are resolved
by default and perms::symlink_nofollow must be given to change this.
This issue has not yet been moved to Ready status, and I will revert if it
doesn't get moved at the current meeting. However I feel confident that it
will and it's nice to have implementations when moving issues.
llvm-svn: 273328
The filesystem tests were expecting the paths to the build/source directories
did not contain any symlinks. This patch resolves those symlinks before running
the test suite.
llvm-svn: 273323
Summary:
An implementation of std::experimental::propagate_const from Library Fundamentals Technical Specification v2.
No tests are provided for disallowed types like fancy pointers or function pointers as no code was written to handle these.
Reviewers: EricWF, mclow.lists
Differential Revision: http://reviews.llvm.org/D12486
llvm-svn: 273122
* Fix non-null violation in strstream.cpp
Overflow was calling memcpy with a null parameter and a size of 0.
* Fix std/atomics/atomics.flag/ tests:
a.test_and_set() was reading from an uninitialized atomic, but wasn't
using the value. The tests now clear the flag before performing the
first test_and_set. This allows UBSAN to test that clear doesn't read
an invalid value.
* Fix std/experimental/algorithms/alg.random.sample/sample.pass.cpp
The tests were dereferencing a past-the-end pointer to an array so that
they could do pointer arithmetic with it. Instead of dereference the iterator
I changed the tests to use the special 'base()' test iterator method.
* Add -fno-sanitize=float-divide-by-zero to suppress division by zero UBSAN diagnostics.
The tests that cause float division by zero are explicitly aware that they
are doing that. Since this is well defined for IEEE floats suppress the warnings
for now.
llvm-svn: 273107
Use strtof and strtod for floats and doubles respectively instead of
always using strtold. The other parts of the change are already implemented
in libc++.
This patch also has a drive by fix to wbuffer_convert::underflow() which
prevents it from calling memmove(buff, null, 0).
llvm-svn: 273106
We all know <__tree> and <__hash_table> have plenty of UB that UBSan faithfully
finds. I am working on fixing this. However the noisy output from these failures
prevent automatically detecting regressions elsewhere.
This patch adds a blacklist file for these failures so I can later set up a
UBSAN buildbot.
llvm-svn: 273104
* Fix passing a negative number as either tv_usec or tv_nsec. When file_time_type
is negative and has a non-zero sub-second value we subtract 1 from tv_sec
and make the sub-second duration positive.
* Detect and report when 'file_time_type' cannot be represented by time_t. This
happens when using large/small file_time_type values with a 32 bit time_t.
There is more work to be done in the implementation. It should start to use
stat's st_mtim or st_mtimeval if it's provided as an extension. That way
we can provide a better resolution.
llvm-svn: 273103
fstream has a switch over ios_base::seekdir which provides a defensive default
case. This seems like the right thing for fstream to do, but we need to disable
clangs warning during the build to allow this.
llvm-svn: 273092
Single threaded builds often don't provide a monotonic clock, so we can't
always provide a monotonic SleepFor(...) implementation. Hopefully this
won't cause the builds to hang.
llvm-svn: 273091
This patch fixes the following bugs, all of which were discovered while
testing a 32 bit build on a 64 bit machine.
* path.itr/iterator.pass.cpp has undefined behavior.
'path::iterator' stashes the value of the element inside the iterator.
This violates the BiDirIterator requirements but is allowed for path::iterator.
However this means that using reverse_iterator<path::iterator> has undefined
behavior because it assumes that 'Iter tmp = it; return *tmp' will not create
a dangling reference. However it does, and this caused this particular test
to fail.
* path.native.obs/string_alloc.pass.cpp tested the SSO with a long string.
On 32 bit builds std::wstring only has the SSO for strings of size 2. The
test was using a string of size 4.
* fs.op.space/space.pass.cpp had overflows while calculating the expected values.
The fix here is to convert the statvfs data members to std::uintmax_t before
multiplying them. The internal implementation already does this but the tests
needed to do it as well.
llvm-svn: 273078
Summary:
Currently the implementation of [util.smartptr.shared.atomic] is provided only when using Clang, and not with GCC. This is a relic of not having a GCC implementation of <atomic>, even though <atomic> isn't actually used in the implementation. This patch enables support for atomic shared_ptr functions when using GCC.
Note that this is not a header only change. Previously only Clang builds of libc++.so would provide the required symbols. There is no reason for this restriction.
After this change both Clang and GCC builds should be binary compatible with each other WRT these symbols.
Reviewers: mclow.lists, rmaprath, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21407
llvm-svn: 273076
Currently 4 tests are failing on the ARM buildbot. To try and diagnose each
of the failures this patch does the following:
1) path.itr/iterator.pass.cpp
* Temporarily print iteration sequence to see where its failing.
2) path.native.obs/string_alloc.pass.cpp
* Remove test that ::new is not called when constructing a short string
that requires a conversion. Since during the conversion global locale
objects might be constructed.
3) fs.op.funcs/space.pass.cpp
* Explicitly use uintmax_t in the implementation of space, hopefully
preventing possible overflows.
* Add additional tests that check for overflow is the calculation of the
space_info values.
* Add additional tests for the values returned from statfvs.
4) fs.op.funcs/last_write_time.pass.cpp
* No changes made yet.
llvm-svn: 273075
r273060 didn't completely fix the issues in recursive_directory_iterator and
the tests. This patch follows up with more fixes
* Fix bug where recursive_directory_iterator::increment(ec) did not reset
the error code if no failure occurred.
* Fix bad assertion in the recursive_directory_iterator::increment(ec) test
that would only fire for certain iteration orders.
llvm-svn: 273070
There are two fixes in this patch:
* Fix bug where the constructor of recursive_directory_iterator did not reset
the error code if no failure occurred.
* Fix tests were dependent on the iteration order of the test directories.
llvm-svn: 273060
Add the completed std::experimental::filesystem implementation and tests.
The implementation supports C++11 or newer.
The TS is built as part of 'libc++experimental.a'. Users of the TS need to
manually link this library. Building and testing the TS can be disabled using
the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'.
Currently 'libc++experimental.a' is not installed by default. To turn on the
installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'.
llvm-svn: 273034
CloudABI has gained the mblen_l() function in the meantime that does
properly return whether the character set has shift-states (read:
never).
llvm-svn: 272886
Summary:
Android didn't gain GNU's strerror_r until Marshmallow. If we're
building libc++ against something older (we build the NDK library
against the oldest release we support, currently Gingerbread), fall
back to the POSIX version.
Reviewers: mclow.lists, EricWF
Subscribers: tberghammer, danalbert, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D21402
llvm-svn: 272827
Summary:
In test/support/test_allocator.h, fix construct() to avoid moving immovable types.
This improves the allocator's conformance, and fixes compiler errors with MSVC's STL. The scenario is when the allocator is asked to construct an object of type X that's immovable (deleted copy/move ctors), but implicitly constructible from an argument type A. When perfectly forwarded, X can be (explicitly) constructed from A, and everything is fine. That's std::allocator's behavior, and the Standard's default when a user allocator's construct() doesn't exist. The previous implementation of construct() here mishandled this scenario. Passing A to this construct() would implicitly construct an X temporary, bound to (non-templated) T&&. Then construct() would attempt to move-construct X from that X temporary, but X is immovable, boom.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21094
llvm-svn: 272747
Summary:
Libc++ reexports symbols from the system libc++abi using -reexport_symbols_list. This can cause a linker failure if the list contains symbols not defined in the system libc++abi.
This patch attempts to detect the OS X version and use it to determine the correct symbol list.
It's my understanding that `lib/libc++abi2.exp` should be used on 10.9 and greater. Otherwise 'lib/libc++abi.exp' should be used
This fixes PR25666 (https://llvm.org/bugs/show_bug.cgi?id=25666)
Reviewers: mclow.lists, bcraig, dexonsmith, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20772
llvm-svn: 272723
Summary:
This patch implements the variadic `lock_guard` paper.
Making `lock_guard` variadic is a ABI breaking change because the specialization `lock_guard<_Mutex>` mangles differently then when it was the primary template. This change only provides variadic `lock_guard` in ABI V2 or when `_LIBCPP_ABI_VARIADIC_LOCK_GUARD` is defined.
Note that in ABI V2 `lock_guard` must always be declared as a variadic template, even in C++03, in order to keep the ABI consistent. For this reason `lock_guard` is forward declared as a variadic template in all standard dialects and therefore depends on variadic templates being provided as an extension in C++03. All supported versions of Clang and GCC provide this extension.
Reviewers: mclow.lists
Subscribers: K-ballo, mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D21260
llvm-svn: 272634
Summary:
system_error::message() uses `strerror` for the generic and system categories. This function is not thread safe.
The fix is to use `strerror_r`. It has been available since 2001 for GNU libc and since BSD 4.4 on FreeBSD/OS X.
On platforms with GNU libc the extended version is used which always returns a valid string, even if an error occurs.
In single-threaded builds `strerror` is still used.
See https://llvm.org/bugs/show_bug.cgi?id=25598
Reviewers: majnemer, mclow.lists
Subscribers: erik65536, cfe-commits, emaste
Differential Revision: http://reviews.llvm.org/D20903
llvm-svn: 272633
Summary:
I haven't added it to all the tests, just those that fail without it
(those that aren't header only).
Reviewers: EricWF, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21247
llvm-svn: 272443
Patch by Laman Sole <laxman.g@partner.samsung.com>, Sebastian Pop
<s.pop@samsung.com>, Aditya Kumar <aditya.k7@samsung.com>
Differential Revision: http://reviews.llvm.org/D21103
llvm-svn: 272401
Some pthread implementations do not like being called pthead_join()
with the pthread_t argument set to 0, and causes a segfault. This
patch fixes this issue by validating the pthread_t argument before
invoking pthread_join().
NFC.
Differential revision: http://reviews.llvm.org/D20929
Change-Id: Ief817c57bd0e1f43cbaa03061e02417d6a180c38
Reviewers: EricWF
llvm-svn: 271634
LWG issue 2218 relaxes a restriction on how containers can call
Alloc::construct(...) and Alloc::destroy(...). There is nothing new to test.
llvm-svn: 271477
Eric Fiselier