x86-64 ILP32 mode (x32) uses 32-bit size_t, so share the code with ix86 to zero out padding bits, not with x86-64 LP64 mode.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D91349
I think people were sometimes parenthesizing `(foo::max)()` out of
misplaced concern that an unparenthesized `foo::max()` would trip up
Windows' `max(a,b)` macro. However, this is not the case: `max(a,b)`
should be tripped up only by an unparenthesized call to `foo::max(a,b)`,
and in fact we already do `_VSTD::max(a,b)` all over the place anyway
without any guards.
However, in order to do it without guards, we must also
wrap the header in _LIBCPP_PUSH_MACROS, which <span> was not.
Differential Revision: https://reviews.llvm.org/D92240
This patch updates algorithms in <numeric> to use std::move
based on p0616r0. Moving values instead of copying them
creates huge speed improvements (see the paper for details).
Differential Revision: https://reviews.llvm.org/D61170
There were a couple of places where we needed to call the underlying
platform's aligned allocation/deallocation function. Instead of having
the same logic all over the place, extract the logic into a pair of
helper functions __libcpp_aligned_alloc and __libcpp_aligned_free.
The code in libcxxabi/src/fallback_malloc.cpp looks like it could be
simplified after this change -- I purposefully did not simplify it
further to keep this change as straightforward as possible, since it
is touching very important parts of the library.
Also, the changes in libcxx/src/new.cpp and libcxxabi/src/stdlib_new_delete.cpp
are basically the same -- I just kept both source files in sync.
The underlying reason for this refactoring is to make it easier to support
platforms that provide aligned allocation through C11's aligned_alloc
function instead of posix_memalign. After this change, we'll only have
to add support for that in a single place.
Differential Revision: https://reviews.llvm.org/D91379
Implements P1956: On the names of low-level bit manipulation functions.
Users may use older versions of libc++ or other standard libraries with the old names. In order to keep compatibility the old functions are kept, but marked as deprecated.
The patch also adds a new config macro `_LIBCPP_DEPRECATED_MSG`. Do you prefer a this is a separate patch?
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D90551
Zoe Carver says: "We decided that libc++ only supports C++20 constexpr algorithms
when `is_constant_evaluated` is also supported. Here's a link to the discussion."
https://reviews.llvm.org/D65721#inline-735682
Remove _LIBCPP_HAS_NO_BUILTIN_IS_CONSTANT_EVALUATED from tests, too.
See Louis's 5911e6a885 if needed to fix bots.
I've applied `UNSUPPORTED: clang-8` preemptively to the altered tests;
I don't know for sure that this was needed, because no clang-8 buildbots
are triggered on pull requests.
Fixes LWG issue 2724: "The protected virtual member functions of memory_resource should be private."
Differential Revision: https://reviews.llvm.org/D66615
This reverts commit 620adacf87.
Fix: unsupport C++03 for the new test, define helpers before __swap_allocator
(1) Add _VSTD:: qualification to __swap_allocator.
(2) Add _VSTD:: qualification consistently to __to_address.
(3) Add some more missing _VSTD:: to <vector>, with a regression test.
This part is cleanup after d9a4f936d0.
Note that a vector whose allocator actually runs afoul of any of these ADL calls will
likely also run afoul of simple things like `v1 == v2` (which is also an ADL call).
But, still, libc++ should be consistent in qualifying function calls wherever possible.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/
Differential Revision: https://reviews.llvm.org/D91708
Not all platforms support priority attribute. I'm moving conditional definition of this attribute to `include/__config`.
Reviewed By: #libc, aaron.ballman
Differential Revision: https://reviews.llvm.org/D91565
(1) Add _VSTD:: qualification to __swap_allocator.
(2) Add _VSTD:: qualification consistently to __to_address.
(3) Add some more missing _VSTD:: to <vector>, with a regression test.
This part is cleanup after d9a4f936d0.
Note that a vector whose allocator actually runs afoul of any of these ADL calls will
likely also run afoul of simple things like `v1 == v2` (which is also an ADL call).
But, still, libc++ should be consistent in qualifying function calls wherever possible.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/
Differential Revision: https://reviews.llvm.org/D91708
This commit makes it clear that the typeinfo comparison implementation
is automatically selected by default, and that the CMake option only
overrides the value. This has been a source of confusion and bugs ever
since we've introduced complexity in that area, so I'm trying to simplify
it while still allowing for some control on the implementation.
Differential Revision: https://reviews.llvm.org/D91574
These functions are called directly from the public installed
headers, and thus need to be exported in DLL builds, just like
some other functions in the same header (e.g. snprintf_l).
This fixes e.g. test/std/localization/locale.categories/category.numeric/locale.num.get/facet.num.get.members/get_float.pass.cpp
in mingw configurations.
Differential Revision: https://reviews.llvm.org/D91328
These changes cause substantial binary size increases for non-opt builds.
For example, the visit.pass.cpp test grows from 20k to 420k.
Further work will be done to re-land this patch without the size increases,
but that work is proving too tricky to fix forward.
This patch fully reverts:
* 35d2269111
And it partially reverts:
* bb43a0cd4a
The latter of which added XFAIL's to new variant tests
because the new implementation needlessly makes non-throwing code
paths in variant invoke throwing code.
This means the reverted change also breaks source backwards compat
with code compiled on OS X targeting older system dylibs. There is no
need for this to be the case. We should fix it before recommitting.
Reviewed as:
https://reviews.llvm.org/D91662
Erroring out prevents the library from working with other file formats
(e.g. in embedded). Since that error does not guard us from doing something
incorrect, it seems fine to just remove it.
This patch adds a shim for missing time functions on z/OS, and adds a
layer of indirection to account for differences in the timespec struct
on different systems.
This was originally committed as 173b51169b and reverted in 777ca48c9f
because the original commit also checked-in unrelated changes.
Differential Revision: https://reviews.llvm.org/D87940
The unavailability of posix_memalign on z/OS forces us to define _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION'. The use of posix_memalign is being used in libcxx/src/new.cpp.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D90178
This commit adds new explicit instantiations for some classes in <iostream>
in the library. This is done after noticing that many programs that use
streams end up containing weak definitions of these classes, which has a
negative impact on both code size and load times (due to the need to
resolve weak symbols at load time). Note that we are just adding the
additional explicit instantiations for the `char` specializations, since
the `wchar_t` specializations are not used as often, and as a result there
wouldn't be a clear benefit.
This change is not an ABI break, since we are just adding additional
symbols.
Differential Revision: https://reviews.llvm.org/D90677
This patch is one part of many steps required to build libc++ and libc++abi libraries on z/OS. This particular deals with time related functions and consists of the following 3 parts.
1) Initialization of :timeval within libc++ library need to be adjusted to work on z/OS.
The following is z/OS definition from time.h which includes additional aggregate member.
typedef signed int suseconds_t;
struct timeval {
time_t tv_sec;
char tv_usec_pad[4];
suseconds_t tv_usec;
};
In contracts the following is definition from time.h on Linux.
typedef long int __suseconds_t;
struct timeval
{
__time_t tv_sec;
__suseconds_t tv_usec;
};
2) In addition, retrieving ::timespec within libc++ library needs to be adjusted to compensate the difference of some of the members of ::stat depending of the target host.
Here are the 2 members in conflict on z/OS extracted from stat.h.
struct stat {
...
time_t st_atime;
time_t st_mtime;
...
};
In contract here is Linux equivalent from stat.h.
struct stat
{
...
struct timespec st_atim;
struct timespec st_mtim;
...
};
3) On Linux both members are of type timespec whereas on z/OS an object of type timespec need to be constructed first before retrieving it within libc++ library.
The libc++ header file __threading_support calls nanosleep, which is not available on z/OS.
The equivalent functionality will be implemented by using both sleep() and usleep().
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D87940
This is consistent with what's done in locale.cpp, and it ensures that
we get the default rune table whenever _LIBCPP_PROVIDES_DEFAULT_RUNE_TABLE
is defined, regardless of the actual platform.
Differential Revision: https://reviews.llvm.org/D91074
This patch changes how linear_congruential_engine picks its randomization
algorithm. It adds two restrictions, `_OverflowOK` and `_SchrageOK`.
`_OverflowOK` means that m is a power of two so using the classic
`(a * x + c) % m` will create a meaningless overflow. The second checks
that Schrage's algorithm will produce results that are in bounds of min
and max. This patch fixes https://llvm.org/PR27839.
Differential Revision: D65041
The aim of this patch is to enable POSIX _l functions for z/OS. In particular, the functions are provided with libc++ and this patch resorts to the fallback functions. Nonetheless, the functions are being added so the implementation of the ctype<> member functions can call them. The following changes were needed to allow for a successful build when using the libc++ library for z/OS.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D90319
The current way we test this is pretty cheap, i.e. we download previously
released macOS dylibs and run against that. Ideally, we would require a
full host running the appropriate version of macOS, and we'd execute the
tests using SSH on that host. But since we don't have such hosts available
easily for now, this is better than nothing.
At the same time, also fix some tests that were failing when back
deploying.
Differential Revision: https://reviews.llvm.org/D90869
Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.
For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.
In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.
Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).
Differential Revision: https://reviews.llvm.org/D90843
Those are part of the library, and shipping them just adds a tiny bit of
size to the distribution. This was originally added in b422ecc7de to
make it possible to match the Makefile build, which doesn't exist anymore.
The upside is build system simplification.
Before 6db314e86b, when running cmake with clang, libcxx, and
compiler-rt enabled, building `ninja all` would run the
generate-cxx-headers target, due to the sanitizers depending on it.
After 6db314e86b, if LIBCXX_ENABLE_SHARED and LIBCXX_ENABLE_STATIC
and LIBCXX_INCLUDE_TESTS and LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY are
disabled (https://reviews.llvm.org/D82702#2153627), `ninja all`
no longer copies the libcxx headers, which means clang can't compile
programs like `#include <string>` on macOS.
Explicitly add the copy target to the all target to restore the old
behavior.
On windows, wchar_t is 16 bit, while we might be widening chars to
char32_t.
This cast had been present since the initial commit, and removing it
doesn't seem to make any tests fail.
Differential Revision: https://reviews.llvm.org/D90228
When porting libc++ to embedded systems, it can be useful to drop support
for localization, which these systems don't implement or care about.
Differential Revision: https://reviews.llvm.org/D90072
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
On old Apple platforms (pre 10.9), we couldn't rely on the iostreams
explicit instantiations being part of the dylib. However, we don't
support back-deploying to such old deployment targets anymore, so the
workaround can be dropped.
This commit should really be named "Workaround external projects depending
on libc++ build system implementation details". It seems that the compiler-rt
build (and perhaps other projects) is relying on the fact that we copy libc++
and libc++abi headers to `<build-root>/include/c++/v1`. This was changed
by 5d796645, which moved the headers to `<build-root>/projects/libcxx/include/c++/v1`
and broke the compiler-rt build.
I'm committing this workaround to fix the compiler-rt build, but we should
remove reliance on implementation details like that. The correct way to
setup the compiler-rt build would be to "link" against the `cxx-headers`
target in CMake, or to run `install-cxx-headers` using an appropriate
installation prefix, and then manually add a `-I` path to that location.
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D89041
This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we are targeting a static or shared
libc++ build.
This patch is technically ABI breaking, but only for a very specific
configuration that no vendor should be shipping.
Note that _LIBCPP_BUILD_STATIC is not normally defined when building
libc++.a, but instead it must be manually provided by the user or the
__config_site.
Differential Revision: https://reviews.llvm.org/D32838
We included <istream> and <ostream> from <random>, but really it is
sufficient to include <iosfwd> if we make sure we access ios_base
members through a dependent type. This allows us to break a hard
dependency of <random> on locales.
Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes it possible to
build and test libc++ for such platforms, i.e. without std::random_device.
Surprisingly, the only functionality that doesn't work on such platforms
is std::random_device itself -- everything else in <random> still works,
one just has to find alternative ways to seed the PRNGs.
Due to the need to support compilers that implement builtin operator
new/delete but not their align_val_t overloaded versions, there was a
lot of complexity. By assuming that a compiler that supports the builtin
new/delete operators also supports their align_val_t overloads, the code
can be simplified quite a bit.
Differential Revision: https://reviews.llvm.org/D88301
We don't support any compiler that doesn't support variadics and rvalue
references in C++03 mode, so these workarounds can be dropped. There's
still *a lot* of cruft related to these workarounds, but I try to tackle
a bit of it here and there.
__clear_and_shrink() was added in D41976, and a test was added alongside
it to make sure that the string invariants were maintained. However, it
appears that the test never ran under UBSan before, which would have
highlighted the fact that it doesn't actually maintain the string
invariants.
Differential Revision: https://reviews.llvm.org/D88849
Some system headers define __constructor and __destructor macros (for
Clang attributes constructor and destructor). While this is badly
behaved, it is easy for libc++ to work around this issue.
The debug mode always had three possibilities:
- _LIBCPP_DEBUG is undefined => no assertions
- _LIBCPP_DEBUG == 0 => some assertions
- _LIBCPP_DEBUG == 1 => some assertions + iterator checks
This was documented that way, however the code did not make this clear
at all. The discrepancy between _LIBCPP_DEBUG and _LIBCPP_DEBUG_LEVEL
was especially confusing. I reworked how the various macros are defined
without changing anything else to make the code clearer.
This seems to have been added a long time ago as a temporary help
for debugging some <regex> issue, but it's really the same as
_LIBCPP_EXTERN_TEMPLATE.
This is a partial revert of D62155. Rather than copying libc++ headers
into the build directory to be later overwritten by the final headers,
use -isystem flag to access libc++ headers during CMake checks. This
should address the occasional flake we've seen, especially on Windows
builders where CMake fails to overwrite __config with the final version.
Differential Revision: https://reviews.llvm.org/D88454
* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.
* Mark the constructor as consteval to ensure that no code is emitted
for it whenever possible.
* Add a honeypot constructor to reject all non-int arguments, so that
the only argument that can arrive at the real constructor is the
literal 0.
This results in better generated code, and rejecting invalid comparisons
against nullptr, 0L, and so on, while also rejecting invalid comparisons
against (1-1) and similar that would be allowed if we required an
integer constant expression with value 0.
Differential Revision: https://reviews.llvm.org/D85051
We're technically not allowed by the Standard to call ::operator new in
constexpr functions like __libcpp_allocate. Clang doesn't seem to complain
about it, but GCC does.
fdc41e11f was reverted in e46c1def5 because it broke the C++11 build.
We shouldn't be using enable_if_t in C++11, instead we must use
enable_if<...>::type.
This reverts commit fdc41e11f9. It causes the
libcxx/modules/stds_include.sh.cpp test to fail with:
libcxx/include/ostream:1039:45: error: no template named 'enable_if_t'; did you mean 'enable_if'?
template <class _Stream, class _Tp, class = enable_if_t<
Still investigating what's causing this and reverting in the meantime to get
the bots green again.
Libc++ had an issue where nonsensical code like
decltype(std::stringstream{} << std::vector<int>{});
would compile, as long as you kept the expression inside decltype in
an unevaluated operand. This turned out to be that we didn't implement
LWG1203, which clarifies what we should do in that case.
rdar://58769296
This commit adds std::construct_at, and marks various members of
std::allocator_traits and std::allocator as constexpr. It also adds
tests and turns the existing tests into hybrid constexpr/runtime tests.
Thanks to Richard Smith for initial work on this, and to Michael Park
for D69803, D69132 and D69134, which are superseded by this patch.
Differential Revision: https://reviews.llvm.org/D68364
Mitsuru Kariya reported the map operations insert_or_assign with a hint
violates the complexity requirement. The function no longer uses a lower_bound,
which caused the wrong complexity.
Fixes PR38722: [C++17] std::map::insert_or_assign w/ hint violate complexity requirements
Differential Revision: https://reviews.llvm.org/D62779
We don't support GCC in C++03 mode, and Clang provides variadic templates
even in C++03 mode. So there's effectively no supported compiler that
doesn't support variadic templates.
This effectively gets rid of all uses of _LIBCPP_HAS_NO_VARIADICS, but
some workarounds for the lack of variadics remain.
Otherwise, we're declaring a non-static member function, and that
gives errors in C++11 because of the change of semantics between
C++11 and C++14 for non-const constexpr member functions.
This was always intended to be a friend declaration.
https://llvm.org/PR45099 notes (correctly) that we're inconsistent in memory
allocation in `std::any`. We allocate memory with `std::allocator<T>::allocate`,
construct with placement new, destroy by calling the destructor directly, and
deallocate by calling `delete`. Most of those are customizable by the user,
but in different ways.
The standard is silent on how these things are to be accomplished.
This patch makes it so we use `allocator_traits<allocator<T>>` for all
of these operations (allocate, construct, destruct, deallocate).
This is, at least, consistent.
Fixes https://llvm.org/PR45099.
Differential Revision: https://reviews.llvm.org/D81133
This patch makes `std::rotate` a constexpr. In doing so, this patch also
updates the internal `__move` and `__move_backward` funtions to be
constexpr.
This patch was previously reverted in ed653184ac because it was missing
some UNSUPPORTED markup for older compilers. This commit adds it.
Differential Revision: https://reviews.llvm.org/D65721
cppreference lists the support for this paper as partial.
I found 4 functions which the paper marks as `constexpr`,
but did not use the appropriate macro.
Differential Revision: https://reviews.llvm.org/D84275
This patch makes `std::rotate` a constexpr. In doing so, this patch also
updates the internal `__move` and `__move_backward` funtions to be
constexpr.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D65721
In C++20, since P0896R4, std::ostream_iterator and std::ostreambuf_iterator
must have std::ptrdiff_t instead of void as a difference_type.
Tests by Casey Carter (thanks!).
Differential Revision: https://reviews.llvm.org/D87459
D56913 introduced the _LIBCPP_FREESTANDING macro and guarded its
definition by:
#ifndef __STDC_HOSTED__
# define _LIBCPP_FREESTANDING
#endif
However, __STDC_HOSTED__ is defined as 0 in freestanding implementations
instead of undefined, which means that _LIBCPP_FREESTANDING would never
get defined. This patch corrects the above as:
#if __STDC_HOSTED__ == 0
# define _LIBCPP_FREESTANDING
#endif
Differential Revision: https://reviews.llvm.org/D86055
This commit re-applies 99f3b231cb, which was reverted in 8142425727
because it broke the modules build. The modules failure was a circular
dependency between the Darwin module and __config. Specifically, the
issue was that if <__config> includes a system header, the std_config
module depends on the Darwin module. However, the Darwin module already
depends on the std_config header because some of its headers include
libc++ headers like <ctype.h> (they mean to include the C <ctype.h>,
but libc++ headers are first in the header search path).
This is fixed by moving the workaround to <ctime> only.
https://llvm.org/PR47208
rdar://68157284
This reverts commit 99f3b231cb. It breaks
libcxx/modules/stds_include.sh.cpp on macOS as the new include to sys/cdefs.h
causes a dependency from __config to the Darwin module (which already has
a dependency on __config). This cyclic dependency breaks compiling the std
module which breaks compiling pretty much every program with ToT libc++ and
enabled modules.
I'll revert for now to get the bots green again. Sorry for the inconvenience.
There are currently some failures caused by this change internally. I'm working
to debug them and hopefully these series of patches should be recommitted by
the end of the week.
Thank you to Micheal Park for the contributions, and for allowing the temporary
rollback.
The commits reverted by this change are:
7d15ece79ce0ec7a020602197f7e50a175a96517
timespec_get is not available in Apple SDKs when (__DARWIN_C_LEVEL >= __DARWIN_C_FULL)
isn't true, which leads to libc++ trying to import ::timespec_get into
namespace std when it's not available. This issue has been reported to
Apple's libc, but we need a workaround in the meantime.
https://llvm.org/PR47208
rdar://68157284
A parameter pack is deemed to be uncaptured, which is bogus... but it seems to
be because it's within an expression that involves `decltype` of an uncaptured
pack or something: https://godbolt.org/z/b8z3sh
Drive-by fix for uglified name.
Differential Revision: https://reviews.llvm.org/D86827
This implements the part of P0619R4 related to the default allocator.
This is incredibly important, since otherwise there is an ABI break
between C++17 and C++20 w.r.t. the default allocator's size_type on
platforms where std::size_t is not the same as std::make_unsigned<std::ptrdiff_t>.
This fixes a mismatched visibility attribute on the call operator in
addition to making the code clearer. Given this is a simple lambda
in essence, the intent has always been to give it inline visibility.
Fix compilation with -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY when using clang. Now linking target 'cxx_external_threads' with 'cxx-headers'. Fix mismatching visibility for `libcpp_timed_backoff_policy` function in file <__threading_support>.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D86598
We don't support GCC in C++03 mode, and Clang provides rvalue references
even in C++03 mode. So there's effectively no supported compiler that
doesn't support rvalue references.
Differential Revision: https://reviews.llvm.org/D84943
This change fixes errors reported by Control Flow Integrity (CFI) checking when using `std::packaged_task`. The errors mostly stem from casting the underlying storage (`__buf_`) to `__base*`, even if it is uninitialized. The solution is to wrap `__base*` access to `__buf_` behind a getter marked with _LIBCPP_NO_CFI.
Differential Revision: https://reviews.llvm.org/D82627
Block.h is a pretty common name, which can lead to nasty collisions with
user provided headers. Since we're only getting a few simple declarations
from the header, it's better to declare them manually than to include the
header.
rdar://66384326
Differential Revision: https://reviews.llvm.org/D85035
First, add a TEST_HAS_QUICK_EXIT macro to mirror other C11 features like
TEST_HAS_ALIGNED_ALLOC, and update the tests for that.
Second, get rid of TEST_HAS_C11_FEATURES and _LIBCPP_HAS_C11_FEATURES,
which were only used to ensure that feature macros don't get out of
sync between <__config> and "test_macros.h". This is not necessary
anymore, since we have tests for each individual macro now.
Instead of detecting it automatically but also allowing for the setting
to be specified explicitly, always detect whether exceptions are enabled
based on whether -fno-rtti (or equivalent) is used. It's less confusing
to have a single way of tweaking that knob.
This change follows the lead of 71d88cebfb.
Instead of having complex logic around how to include the libc++ headers
and __config_site, handle that by defining cxx-headers as an INTERFACE
library and linking against it. After this patch, linking against cxx-headers
is sufficient to get the right __config_site include and include paths
for libc++.
Differential Revision: https://reviews.llvm.org/D82702
Thanks to @lewissbaker who pointed out the unnecessary condition in
https://reviews.llvm.org/D81954#inline-756872. Since this codepath does not
make use of `swap` anyway (that codepath is a different branch), we can safely
remove this condition and produce better codegen when all types are nothrow
movable but are potentially-throwing swappable.
See codegen in https://gcc.godbolt.org/z/uDFZjz
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D83274
Instead of detecting it automatically (in libc++) and relying on
_LIBCXXABI_NO_EXCEPTIONS being set explicitly (in libc++abi), always
detect whether exceptions are enabled automatically.
This commit also removes support for specifying -D_LIBCPP_NO_EXCEPTIONS
and -D_LIBCXXABI_NO_EXCEPTIONS explicitly -- those should just be inferred
from using -fno-exceptions (or an equivalent flag).
Allowing both -D_FOO_NO_EXCEPTIONS to be provided explicitly and trying
to detect it automatically is just confusing, especially since we did
specify it explicitly when building libc++abi. We should have only one
way to detect whether exceptions are enabled, but it should be robust.
We've decided to move away from that by requiring that libc++ is built
as part of the monorepo a while ago. This commit removes code pertaining
to that unsupported use case and produces a clear error when the user
violates that.
In fact, building outside of the monorepo will still work as long as
LLVM_PATH is pointing to the root of the LLVM project, although that
is not officially supported.
The runtimes build includes libcxx/include/CMakeLists.txt directly instead
of going through the top-level CMake file. This not-very-hygienic inclusion
caused some variables like LIBCXX_BINARY_DIR not to be defined properly,
and the config_site generation logic to fail after landing 53623d4aa7.
This patch works around this issue by defining the missing variables.
However, the proper fix for this would be for the runtimes build to
always go through libc++'s top-level CMakeLists.txt. Doing otherwise
is unsupported.
Before this patch, the __config_site header was only generated when at
least one __config_site macro needed to be defined. This lead to two
different code paths in how libc++ is configured, depending on whether
a __config_site header was generated or not. After this patch, the
__config_site is always generated, but it can be empty in case there
are no macros to define in it.
More context on why this change is important
--------------------------------------------
In addition to being confusing, this double-code-path situation lead to
broken code being checked in undetected in 2405bd6898, which introduced
the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake setting. Specifically,
the _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT <__config_site> macro was
supposed NOT to be defined unless LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT
was specified explicitly on the CMake command line. Instead, what happened
is that it was defined to 0 if it wasn't specified explicitly and a
<__config_site> header was generated. And defining that macro to 0 had
the important effect of using the non-unique RTTI comparison implementation,
which changes the ABI.
This change in behavior wasn't noticed because the <__config_site> header
is not generated by default. However, the Apple configuration does cause
a <__config_site> header to be generated, which lead to the wrong RTTI
implementation being used, and to https://llvm.org/PR45549. We came close
to an ABI break in the dylib, but were saved due to a downstream-only
change that overrode the decision of the <__config_site> for the purpose
of RTTI comparisons in libc++abi. This is an incredible luck that we should
not rely on ever again.
While the problem itself was fixed with 2464d8135e by setting
LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT explicitly in the Apple
CMake cache and then in d0fcdcd28f by making the setting less
brittle, the point still is that we should have had a single code
path from the beginning. Unlike most normal libraries, the macros
that configure libc++ are really complex, there's a lot of them and
they control important properties of the C++ runtime. There must be
a single code path for that, and it must be simple and robust.
Differential Revision: https://reviews.llvm.org/D80927
We use the _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT macro for that now instead.
I did leave a check behind to make sure that nobody was still using the old
macro name. I'll remove it a couple of months down the road.
Similar to <concepts>, we need to protect the header and test against
inclusion and being run if concepts aren't supported by the compiler.
Differential Revision: https://reviews.llvm.org/D82171
Summary:
This change adds local 'end' and 'pos' variables for the main loop inmstead of using the ConstructTransaction variables directly.
We observed that not all vector initialization and resize operations got properly vectorized, i.e., (partially) unrolled into XMM stores for floats.
For example, `vector<int32_t> v(n, 1)` gets vectorized, but `vector<float> v(n, 1)`. It looks like the compiler assumes the state is leaked / aliased in the latter case (unclear how/why for float, but not for int32), and because of this fails to see vectorization optimization?
See https://gcc.godbolt.org/z/UWhiie
By using a local `__new_end_` (fixed), and local `__pos` (copied into __tx.__pos_ per iteration), we offer the compiler a clean loop for unrolling.
A demonstration can be seen in the isolated logic in https://gcc.godbolt.org/z/KoCNWv
The com
Reviewers: EricWF, #libc!
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D82111
Summary:
In the case where `swap` is `noexcept`, we should avoid the extension to provide strong-exception guarantee.
Fixes https://bugs.llvm.org/show_bug.cgi?id=46342
Reviewers: #libc, ldionne
Reviewed By: #libc, ldionne
Subscribers: dexonsmith, mclow.lists, miscco, ldionne, zoecarver, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D81954
The Standard documents the signature of std::advance as
template <class Iter, class Distance>
constexpr void advance(Iter& i, Distance n);
Furthermore, it does not appear to put any restriction on what the type
of Distance should be. While it is understood that it should usually
be std::iterator_traits::difference_type, I couldn't find any wording
that mandates that. Similarly, I couldn't find wording that forces the
distance to be a signed type.
This patch changes std::advance to accept any type in the second argument,
which appears to be what the Standard mandates. We then coerce it to the
iterator's difference type, but that's an implementation detail.
Differential Revision: https://reviews.llvm.org/D81425
The availability markup for bad_optional_access marked it as being added
in MacOS 10.14 and aligned releases, however it appears to have been added
in Mac OS 10.13 and aligned releases.
This effectively implements the resolution of LWG3231, which mandates
that calling year_month_day_last::day() on an invalid year_month_day_last
is unspecified behavior. Before this change, it was undefined behavior.
Differential Revision: https://reviews.llvm.org/D81477
This reverts commit 0c148430cf, which added an assertion in day().
The Standard doesn't allow day() to crash -- instead it says that the
result is unspecified.
Differential Revision: https://reviews.llvm.org/D70346
All compilers supported by libc++ have rvalues in C++03 mode so, there is no need for this non-rvalue overload.
Differential Revision: https://reviews.llvm.org/D80881
Libc++ provides support for <thread> in C++03 as an extension. Furthermore,
it does not support any compiler that doesn't have rvalue references. It
is hence possible to provide the move constructor and move assignment
operator in C++03.
Like we do for empty std::array, make sure we have assertions in place
for obvious out-of-bounds issues in std::array when the debug mode is
enabled (which isn't by default).
The Standard is currently unimplementable. We have to pick between:
1. Not implementing constexpr support properly in std::array<T, 0>
2. Making std::array<T, 0> non-trivial even when T is trivial
3. Returning nullptr from std::array<T, 0>::begin()
Libc++ initially picked (1). In 77b9abfc8e, we started implementing constexpr properly, but lost the guarantee of triviality. Since it seems like both (1) and (2) are really important, it seems like (3) is the only viable option for libc++, after all. This is also what other implementations are doing.
This patch moves libc++ from (1) to (3).
It also:
- Improves the test coverage for the various ways of initializing std::array
- Adds tests for the triviality of std::array
- Adds tests for the aggregate-ness of std::array
Reviewed By: #libc, miscco, EricWF, zoecarver
Differential Revision: https://reviews.llvm.org/D80821
When the __config_site header is generated, but LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT
wasn't specified, _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT would be defined
to 0, which was the NonUnique RTTI comparison implementation. The intent
was to use the Unique RTTI comparison implementation in that case, which
caused https://llvm.org/PR45549.
Instead, use a proper "switch" to select the RTTI comparison implementation.
Note that 0 can't be used as a value, because that is treated the same
by CMake as a variable that is just not defined.
Differential Revision: https://reviews.llvm.org/D80037
This commit adds missing support for constexpr in std::array under all
standard modes up to and including C++20. It also transforms the <array>
tests to check for constexpr-friendliness under the right standard modes.
Fixes https://llvm.org/PR40124
Fixes rdar://57522096
Supersedes https://reviews.llvm.org/D60666
Differential Revision: https://reviews.llvm.org/D80452
Summary: Update status page and test synopsis. Add synopsis in <cmath>.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D80456
__test_has_construct.
In C++17 some tests started failing after a521532aa1. This fixes those errors by suppressing the deprecation warning when calling `construct` in `__test_has_construct`. This is the same solution as `__has_destroy_test` already uses.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80481
Summary:
Libcxx only supports compilers with variadics. We can safely remove all "fake" variadic overloads of allocator_traits::construct.
This also provides the correct behavior if anything other than exactly one argument is supplied to allocator_traits::construct in C++03 mode.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80067
Summary:
As described in the bug report:
The commit a8b9f59e8caf378d56e8bfcecdb22184cdabf42d "Implement feature test macros using a script" added test features macros for libc++. Among others, it added `__cpp_lib_hardware_interference_size`. However, there is nothing like std::hardware_constructive_interference_size nor std::hardware_destructive_interference_size, that should be in header <new>.
* https://bugs.llvm.org/show_bug.cgi?id=41423
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D80431
The two functions don't throw, and the generated code is better when
we explicitly tell the compiler that the functions are noexcept. This
isn't an ABI break because the signatures of the functions stay the
same with or without noexcept.
Fixes https://llvm.org/PR46016
Differential Revision: https://reviews.llvm.org/D80379
Summary:
This LWG issue states that the result of `year_month_day_last::day()` is implementation defined if `ok()` is `false`.
However, from user perspective, calling `day()` in this situation will lead to a (possibly difficult to find) crash.
Hence, I have added an assertion to warn user at least when assertions are enabled.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D70346
Summary: Compilation with -DLIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY was failing due to missing declarations of functions used in libcxx/include/atomic. The lines this commit affects are the places where those functions are defined, now moved to be always defined.
Reviewers: #libc, ldionne
Reviewed By: #libc, ldionne
Subscribers: miyuki, dexonsmith, ldionne, jfb, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80372
This change removes both the member function swap and the free function
overload of swap for std::span. While swap is a member and overloaded
for every other container in the standard library [1], it is neither a
member function nor a free function overload for std::span [2].
Thus the corresponding implementation should be removed.
[1] https://eel.is/c++draft/libraryindex#:swap
[2] https://eel.is/c++draft/span.overview
Differential Revision: https://reviews.llvm.org/D69827
Summary: All supported compilers have rvalues and variadics so we can safely remove the overloads of allocator::construct which are only enabled on compilers without rvalues and variadics.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80068
Summary: All supported compilers have rvalues and variadics so we can safely remove the overloads of allocator::construct which are only enabled on compilers without rvalues and variadics.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80068
Summary: The default constructor for shared_ptr and shared_ptr::__enable_weak_this are both noexcept so, shared_ptr::__create_with_control_block can also be marked noexcept.
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80070
Summary: In std::functional moves the reference out of the `__callable` implementation and replaces `_EnableIfCallable` with `_EnableIfLValueCallable` (`_EnableIfLValueCallable` passes `__callable` an lvalue reference type).
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80071
This implements the relaxed requirements on the std::array constructors of span,
where the type only needs to be convertible to the element type of the span.
Note that the previous tests were not sufficient, as the const array<T, n> constructor
was only tested for compile time and the array<T, N> only during runtime.
Restructure the tests so that we can test conversions as well as both constructors.
Differential Revision: https://reviews.llvm.org/D75706
The default constructor of a static span requires _Extent == 0 so
SFINAE it out rather than using a static_assert
Differential Revision: https://reviews.llvm.org/D71994
Summary:
This LWG issue states that the result of `year_month_day_last::day()` is implementation defined if `ok()` is `false`.
However, from user perspective, calling `day()` in this situation will lead to a (possibly difficult to find) crash.
Hence, I have added an assertion to warn user at least when assertions are enabled.
I am however not aware of the libc++ stand on the desired behaviour.
Reviewers: ldionne, mclow.lists, EricWF, #libc
Reviewed By: ldionne, #libc
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70346
Implements P0414R2:
* Adds support for array types in std::shared_ptr.
* Adds reinterpret_pointer_cast for shared_ptr.
Re-committing now that the leaking tests are fixed.
Differential Revision: https://reviews.llvm.org/D62259
Implements P0414R2:
* Adds support for array types in std::shared_ptr.
* Adds reinterpret_pointer_cast for shared_ptr.
Differential Revision: https://reviews.llvm.org/D62259
This commit should will break libc++ without local submodule visibility, but
the LLVM+modules bots are now all using this mode. Before the Green Dragon
LLDB bot was failing to compile with a libc++ built with this commit as LSV
was disabled on macOS.
Original summary:
libc++ is careful to not fracture overload sets. When one overload
is visible to a user, all of them should be. Anything less causes
subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by
both <cmath> and <cstdlib> we had to do awful things that make
<math.h> and <stdlib.h> have header cycles and be non-modular.
This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads
for floating point numbers, these overloads forward to ::fabs,
which are defined in math.h. Therefore ::abs needed to be in math.h
too. But this required stdlib.h to include math.h and math.h to
include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h
(which math includes), and the floating point overloads of ::abs
have been changed to call __builtin_fabs, which both Clang and GCC
support.
The ostream operator<< is currently broken for std::complex with
specified field widths.
This patch a partial revert of c3478eff7a (reviewed as D71214),
restoring the correct behavior.
Differential Revision: https://reviews.llvm.org/D78816
This patch adds deduction guides to <memory> to allow deducing
construction of shared_ptrs from unique_ptrs, and from weak_ptrs
and vice versa, as specified by C++17.
Differential Revision: https://reviews.llvm.org/D69603
This patch adds `_VSTD::` to some calls to `make_pair` inside the
implementations of searchers, to prevent things exploding if there is
a make_pair in an associated namespace of a user-defined type.
https://godbolt.org/z/xAFG98
Differential Revision: https://reviews.llvm.org/D72640
Summary:
pr42199
When using regex_constants::match_prev_avail, it is defined that
--first is valid, and match_not_bol and match_not_bow should be
ignored. At the moment these flags are not ignored. This fixis that.
Reviewers: ldionne, miyuki, EricWF, mclow.lists, #libc
Reviewed By: ldionne, miyuki, #libc
Subscribers: broadwaylamb, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75622
This relands this commit as it broke the LLDB bot the first time it landed.
See also the discussion on https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
Since D74892 this code should now also work on macOS.
Original description:
libc++ is careful to not fracture overload sets. When one overload
is visible to a user, all of them should be. Anything less causes
subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by
both <cmath> and <cstdlib> we had to do awful things that make
<math.h> and <stdlib.h> have header cycles and be non-modular.
This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads
for floating point numbers, these overloads forward to ::fabs,
which are defined in math.h. Therefore ::abs needed to be in math.h
too. But this required stdlib.h to include math.h and math.h to
include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h
(which math includes), and the floating point overloads of ::abs
have been changed to call __builtin_fabs, which both Clang and GCC
support.
The runtime for Blocks may not be available even though the Blocks
language extension _is_ available. Instead of potentially failing,
this commit is much more conservative and assumes the runtime for
Blocks is only provided on Apple platforms.
Differential Revision: https://reviews.llvm.org/D78757
Marked unsupported for C++03 and C++11 since this test uses alias
declarations, and at least one C++03 bot was failing with
-Wc++11-extensions.
Change-Id: I8c3a579edd7eb83e0bc74e85d116b68f22400161
Summary: We discovered that the compiler may chose not to inline the operator=, which leads to an expensive extra stack frame. This change makes __assign_no_alias always tail called.
Reviewers: EricWF, #libc!
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D77913
The use of the `&& ...` fold expression in std::array's deduction guides
recursively builds a set of binary operator expressions of depth N where
`N` is the number of elements in the initializer.
This is problematic because arrays may be large, and instantiation
depth is limited.
This patch addresses the issue by flattening the SFINAE using
the existing `__all` type trait.
Patch from Christopher Di Bella (cjdb@google.com)
Reviewed as https://reviews.llvm.org/D74291
Adds `std::same_as` to libc++. Since there aren't clang-format rules for
//requires-expressions//, I'll need to disable the formatter in certain areas.
Summary: 5ade17e broke __is_pointer for Objective-C pointer types. This patch fixes the builtin and re-applies the change to type_traits.
Tags: #clang, #libc
Differential Revision: https://reviews.llvm.org/D77519
Broke builders that emit different diagnostics. e.g.:
error: 'warning' diagnostics seen but not expected:
Line 13: alias declarations are a C++11 extension
Line 20: alias declarations are a C++11 extension
This reverts commit ff87813715.
Summary:
This is a patch that Android has been carrying in its tree for several
years. This patch upstreams the existing ABI.
There's some historical cruft here. __regex_word used to be a part of
regex_traits rather than ctype_base. Bionic also used to use its own
ctype implementation because the libc++ builtin one wasn't available
yet. Bionic's ctype masks were 8 bits wide and already saturated, so a
wider type needed to be used for the regex mask, and the existing
value was already used so Android needed to specify its own.
Since then Android has migrated to the builtin ctype implementation
and this patch probably should have been dropped then. Unfortunately
that was not noticed at the time, so now we need to keep this to
maintain the current ABI.
Reviewers: EricWF, #libc, ldionne
Reviewed By: #libc, ldionne
Subscribers: dexonsmith, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76171
Always depend on the compiler to have a correct implementation of
max_align_t in stddef.h and don't provide a fallback. For pre-C++11,
require __STDCPP_NEW_ALIGNMENT__ in <new> as provided by clang in all
standard modes. Adjust test cases to avoid testing or using max_align_t
in pre-C++11 mode and also to better deal with alignof(max_align_t)>16.
Document requirements of the alignment tests around natural alignment of
power-of-two-sized types.
Differential revision: https://reviews.llvm.org/D73245
This test regressed with 5ade17e0ca, but we never noticed it because
.pass.mm tests were skipped due to a bug in our Lit config. This commit
fixes is_pointer (by essentially reverting tha part of 5ade17e0ca) and
also adds .pass.mm tests to the list of supported test suffixes.
We can explore how to support __is_pointer with Objective-C++ qualifiers
as a follow-up -- the main goal of this commit is to fix the regression
quickly and make sure all tests of the suite are run.
Based on an issue brought up in https://reviews.llvm.org/D67900, this commit reverts the changes to is_floating_point and is_arithmetic made in D67900.
After D67900 landed, __float128 behaved differently in those two type traits, causing compiler errors in numeric limits (and possibly others).
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
This is a re-application of f383fb40b1, wich was reverted in 04d48111b
because the build bots had not been updated yet. The build bot configurations
have now been updated not to use the deprecated targets, and I verified
that they were using the non-deprecated targets, so we should be good
unless I missed a bot.
Differential Revision: https://reviews.llvm.org/D76104
This reverts commit f383fb40b. It looks like several of our build bots
are still using the legacy target names, so we'll change those before
we commit this change again.
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
There's no doubt this commit will break some CI systems, however the
fix is trivial.
Differential Revision: https://reviews.llvm.org/D76104
In C++03 mode, nullptr is defined by libc++, not the compiler so, we can't use __is_fundamental (because it will return false for nullptr).
Fixes: 5ade17e0ca
This patch updates <type_traits> to use builtin type traits whenever
possible to improve compile times.
Differential Revision: https://reviews.llvm.org/D67900
The current implementation of binomial_distribution is not guaranteed to
converge for certain extreme configurations of the engine and distribution.
This is due to a mistake in the implementation of the algorithm from the
given reference paper. The algorithm in the paper is guaranteed to
terminate but has redundant statements. The current implementation
simplified away the redundancy into a while loop, but it excludes the
return condition of the case where a good sample cannot be returned for
the particular sample being used from the uniform distribution, which is
what causes the infinite loop. This change guarantees termination by
recognizing that a good sample cannot be returned and returning 0 after
breaking the loop. This is also in contrast to the paper because the
return value as specified in the paper violates basic checks in at least
a subset of the extreme cases where the current implementation fails to
terminate. This default return value of 0 is satisfactory for the
extreme case known so far.
Since this is only meant to affect extreme cases where the algorithm
does not terminate anyways, the behavior is expected to remain exactly
the same for all non-extreme cases that have been terminating so far.
Fixes https://llvm.org/PR44847
Differential Revision: https://reviews.llvm.org/D74997
Summary:
The former are like:
libcxx/include/typeinfo:322:11: warning: definition of implicit copy constructor for 'bad_cast' is deprecated because it has a user-declared destructor [-Wdeprecated-copy-dtor]
virtual ~bad_cast() _NOEXCEPT;
^
libcxx/include/typeinfo:344:11: note: in implicit copy constructor for 'std::bad_cast' first required here
throw bad_cast();
^
Fix these by adding an explicitly defaulted copy constructor.
The latter are like:
libcxx/include/codecvt:105:37: warning: dynamic exception specifications are deprecated [-Wdeprecated-dynamic-exception-spec]
virtual int do_encoding() const throw();
^~~~~~~
Fix these by using the _NOEXCEPT macro instead.
Reviewers: EricWF, mclow.lists, ldionne, #libc
Reviewed By: EricWF, #libc
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76150
Summary: The return type modification has already been implemented in rL364840 and rL365290.
Reviewers: ldionne, mclow.lists, EricWF, #libc!
Reviewed By: ldionne
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70275
Due to Clang bug http://llvm.org/PR45151, deprecated attributes are not
picked up on partial specializations. This patch instead applies it to
the first declaration of std::function itself.
Summary:
This is a recommit of https://reviews.llvm.org/D73223 where the added function accidentally ended up inside an idef block.
This change splits the copy constructor up inlining short initialization, and explicitly outlining long initialization into __init_copy_ctor_external() which is the externally instantiated slow path.
For unstable ABI, this has the following changes:
remove basic_string(const basic_string&)
remove basic_string(const basic_string&, const Allocator&)
add __init_copy_ctor_external(const value_type*, size_type)
Quick local benchmark for Copy:
Master
```
---------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------
BM_StringCopy_Empty 3.50 ns 3.51 ns 199326720
BM_StringCopy_Small 3.50 ns 3.51 ns 199510016
BM_StringCopy_Large 15.7 ns 15.7 ns 45230080
BM_StringCopy_Huge 1503 ns 1503 ns 464896
```
With this change
```
---------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------
BM_StringCopy_Empty 1.99 ns 2.00 ns 356471808
BM_StringCopy_Small 3.29 ns 3.30 ns 203425792
BM_StringCopy_Large 13.3 ns 13.3 ns 52948992
BM_StringCopy_Huge 1472 ns 1472 ns 475136
```
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75639
They need to appear before any member functions are ODR used, because
they change the visibility of many of these functions and otherwise
they could end up with hidden visibility in the DSO.
Summary: This review is a mostly trivial change to use an explicit ABI flag for the unstable external template list. This follows the practice for an ABI flag per feature, and provides a spot for the rational / motivation for the flag.
Reviewers: EricWF, ldionne
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75457
The markup wasn't quite right, and that broke compilation with availability
markup enabled. I'm disabling it until I have time to fix it properly to
get the CI mostly green again.
Summary:
This change checks for the case where people want to erase a string to the end, i.e., __n == npos, and inlines the call if so.
This also demonstrates keeping the ABI intact for V1, but inlining the erase() method for unstable.
Reviewers: EricWF, mclow.lists, ldionne
Reviewed By: EricWF, ldionne
Subscribers: smeenai, dexonsmith, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73743
Summary:
The definition of `__libcpp_timed_backoff_policy` and the declaration of
`__libcpp_thread_poll_with_backoff` must not be guarded by
#if !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
because the definitions of `__libcpp_timed_backoff_policy::operator()`
and `__libcpp_thread_poll_with_backoff` aren't guarded by this macro
(and this is correct because these two functions are implemented in
terms of other libc++ functions and don't interact with the host
threading library).
Reviewers: ldionne, __simt__, EricWF, mclow.lists
Reviewed By: ldionne
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75191
Summary:
This change adds the macros _LIBCPP_COMPILER_HAS_BUILTIN_CONSTANT and _LIBCPP_BUILTIN_CONSTANT_P to detect compile time constants, and optimze the code accordingly.
A planned usage example:
The implementation of basic_string::assign() can short-cut a compile time known short string assignent into a fast and compact inlined assignment:
```
basic_string::assign(const value_type* __s) {
if (_LIBCPP_BUILTIN_CONSTANT_P(__s[0]) && length(__s) < __min_cap) {
copy(pointer(), _s, length(__s) + 1);
set_size(length(__s));
} else {
// delegate / tail call out of line implementation
}
}
```
Subscribers: christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73732
std::shared_ptr::allocate_shared isn't in the standard. This commit removes it from libc++. It updates std::allocate_shared to use __create_with_cntrl_block.
Differential Revision: https://reviews.llvm.org/D66178
It turns out that <semaphore.h> is not well-behaved, as it transitively
includes <sys/param.h>, and that one defines several non-reserved macros
that clash with some downstream projects in modular builds. For the time
being, using <sys/semaphore.h> instead gives us the declarations we need
without the macros.
rdar://59744472
Move the implementation of __libcpp_thread_poll_with_backoff
and __libcpp_timed_backoff_policy::operator() out of the
_LIBCPP_HAS_THREAD_API_PTHREAD block. None of the code in these
methods is pthreads specific.
Also add "inline _LIBCPP_INLINE_VISIBILITY" to
__libcpp_timed_backoff_policy::operator(), to avoid errors due to
multiple definitions of the operator. Contrary to
__libcpp_thread_poll_with_backoff (which is a template function),
this is a normal non-templated method.
Differential Revision: https://reviews.llvm.org/D75102
Summary:
In libc++, we normally #ifdef out header content instead of #erroring
out when the Standard in use is insufficient for the requirements of
the header.
Reviewers: EricWF
Subscribers: jkorous, dexonsmith, libcxx-commits, teemperor
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75074
Depend on the compiler to provide a correct implementation of
max_align_t. If __STDCPP_NEW_ALIGNMENT__ is missing and C++03 mode has
been explicitly enabled, provide a minimal fallback in <new> as
alignment of the largest primitive types.
https://reviews.llvm.org/D68480 added those headers and made the std module
only usable with C++14 or later as the submodules were not marked as requiring
C++14 or later. This just adds the missing requires directives.
- Avoid using C++11-and-later features in <atomic>:
Historically, we've supported <atomic> in C++03, so we can't use C++11
features in that header. This is something we really need to change,
since our implementation of <atomic> is starting to accumulate technical
debt because of that.
- Mark a test as unsupported on single threaded systems
- Add missing symbols to the Linux ABI list
Summary: We want to eventually remove it.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D74719
- Add the new symbols to the ABI list on Darwin
- Add XFAIL markup to the tests that require dylib support on older platforms
- Add availability markup for back-deployment
This change splits the _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a _LIBCPP_STRING_V1_EXTERN_TEMPLATE_LIST containing the stable ABI, and a _LIBCPP_STRING_UNSTABLE_EXTERN_TEMPLATE_LIST containing the unstable ABI.
The purpose is to explicitly define and maintain the two lists, where the unstable ABI allows for ABI breaking changes for purposes such as optimization while offering a strong guarantee that any change inside the unstable ABI does not affect the stable ABI.
As per the comment in the __string header, we do still allow etries to be added to the stable ABI list as the c++ versions and corresponding c++ std API changes.
This patch enables throwing exceptions for invalid backreferences
in the constructor when using the basic, extended, grep, or egrep grammar.
This fixes bug 34297.
Differential Revision: https://reviews.llvm.org/D62453
This patch qualifies calls to ref and cref inside ref(reference_wrapper<T>)
and cref(reference_wrapper<T>), respectively. These previously unqualified
calls could break in the presence of user functions called ref/cref inside
associated namespaces: https://gcc.godbolt.org/z/8VfprT
Fixes PR44398.
Differential Revision: https://reviews.llvm.org/D74287
Instead of including <ios> for ios_base::failbit, simply get failbit
member of the template argument. Print directly to a stream instead
of using intermediate ostringstream.
Parsing time: 874ms -> 164ms (-81%)
Thanks to Nikita Kniazev for the patch!
Differential Revision: https://reviews.llvm.org/D71214
The regex backreferences were not properly parsed and used when using
the extended grammar. This change parses them. The issue was found while
working on PR34297.
Thanks to Mark de Wever for the patch!
Differential Revision: https://reviews.llvm.org/D62451
The libc++ __bit_iterator type has weird ABI calling conventions as a
quirk
of the implementation. The const bit iterator is trivial, but the
non-const
bit iterator is not because it declares a user-defined copy constructor.
Changing this now is an ABI break, so this test ensures that each type
is trivial/non-trivial as expected.
The definition of 'non-trivial for the purposes of calls':
A type is considered non-trivial for the purposes of calls if:
* it has a non-trivial copy constructor, move constructor, or
destructor, or
* all of its copy and move constructors are deleted.
This reverts commit 82b47b2978.
This broke Clang and LLDB module builds without -fmodules-local-submodule-visbility.
I'll revert this for now until we have a fix and reland once Clang
can properly handle this code.
See also the discussion in https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
libc++ is careful to not fracture overload sets. When one overload
is visible to a user, all of them should be. Anything less causes
subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by
both <cmath> and <cstdlib> we had to do awful things that make
<math.h> and <stdlib.h> have header cycles and be non-modular.
This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads
for floating point numbers, these overloads forward to ::fabs,
which are defined in math.h. Therefore ::abs needed to be in math.h
too. But this required stdlib.h to include math.h and math.h to
include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h
(which math includes), and the floating point overloads of ::abs
have been changed to call __builtin_fabs, which both Clang and GCC
support.
The static asserts in span<T, N>::front() and span<T, N>::back() are
incorrect as they may be triggered from valid code due to evaluation
of a never taken branch:
span<int, 0> foo;
if (!foo.empty()) {
auto x = foo.front();
}
The problem is that the branch is always evaluated by the compiler,
creating invalid compile errors for span<T, 0>.
Thanks to Michael Schellenberger Costa for the patch.
Differential Revision: https://reviews.llvm.org/D71995
The calculation _Offset + _Count <= size() may overflow, so use
_Count <= size() - _Offset instead. Note that this is safe due to
the previous constraint that _Offset <= size().
Patch by Michael Schellenberger Costa.
Differential Revision: https://reviews.llvm.org/D71998
The extent of the returned span was always std::dynamic_extent, which
is incorrect.
Thanks to Michael Schellenberger Costa for the patch.
Differential Revision: https://reviews.llvm.org/D71997
size_t is always greater than 0, so remove the artifact from the old
index_type.
Patch by Michael Schellenberger Costa.
Differential Revision: https://reviews.llvm.org/D71996
Summary: This change reflows a comment line. This change serves as a no-op test commit
Reviewers: mclow.lists, ldionne, EricWF
Subscribers: dexonsmith, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73552
Summary:
This patch implements https://wg21.link/P0325.
Please mind that at it is my first contribution to libc++, so I may have forgotten to abide to some conventions.
Reviewers: EricWF, mclow.lists, ldionne, lichray
Reviewed By: ldionne, lichray
Subscribers: lichray, dexonsmith, zoecarver, christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69882
Summary:
FreeBSD got `timespec_get` support somewhere in the 12.x timeframe, but
the C++ version check in its system headers was written incorrectly.
This has now been fixed for both FreeBSD 13 and 12.
Add checks for the corresponding `__FreeBSD_version` values, to define
`_LIBCPP_HAS_TIMESPEC_GET` when the function is supported.
Reviewers: emaste, EricWF, ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: arichardson, krytarowski, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71522
This fixes using non-default locales, which currently can crash when
e.g. formatting numbers.
Within the localeconv_l function, the per-thread locale is temporarily
changed with __libcpp_locale_guard, then localeconv() is called,
returning an lconv * struct pointer.
When localeconv_l returns, the __libcpp_locale_guard dtor restores
the per-thread locale back to the original. This invalidates the
contents of the earlier returned lconv struct, and all C strings
that are pointed to within it are also invalidated.
Thus, to have an actually working localeconv_l function, the
function needs to allocate some sort of storage for the returned
contents, that stays valid for as long as the caller needs to use
the returned struct.
Extend the libcxx/win32 specific locale_t class with storage for
a deep copy of a lconv struct, and change localeconv_l to take
a reference to the locale_t, to allow it to store the returned
lconv struct there.
This works fine for libcxx itself, but wouldn't necessarily be right
for a caller that uses libcxx's localeconv_l function.
This fixes around 11 of libcxx's currently failing tests on windows.
Differential Revision: https://reviews.llvm.org/D69505
Summary:
The libcxx test suite auto-detects spaceship operator, but __config does not. This means that the libcxx test suite has been broken for over a month when using top-of-tree clang. This also really ought to be fixed before 10.0.
See: bc633a42dd
Reviewers: chandlerc, mclow.lists, EricWF, ldionne, CaseyCarter
Reviewed By: EricWF
Subscribers: broadwaylamb, hans, dexonsmith, tstellar, llvm-commits, libcxx-commits
Tags: #libc, #llvm
Differential Revision: https://reviews.llvm.org/D72980
Summary:
The compiler already treats them as scalar types, so the library should
too. Furthermore, this allows blocks to be used in more places, for
example in std::optional, which requires an object type.
rdar://problem/57892832
Reviewers: dexonsmith, EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D72708
This reverts commit a8a9c8e0a1.
There are multiple reported failures caused by this change.
Each failure is really weird, but it makes sense to revert
while investigating.
We switched to C11 thread API on Fuchsia in ab9aefe, but further
testing showed that Fuchsia's C11 mutex implementation needs a few
improvements for this to be usable, so we temporarily switch back
to the pthread implementation until those issues are addressed.
Differential Revision: https://reviews.llvm.org/D72862
The C11 API specifies that to initialize a recursive mutex,
mtx_plain | mtx_recursive should be used with mtx_init.
Differential Revision: https://reviews.llvm.org/D72809
The GCC build failures have been addressed, and the LLDB failures were
fixed by LLDB.
I have also verified that the apple-clang 9.0 segfault no longer
occurs.
Original Message:
The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.
This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.
Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.
(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.
This patch is needed in order to work around a GCC bug that fails to
explicitly instantiate a non-template function of a class template when
there is another overload that's a function template.
(See https://godbolt.org/z/4bUQ_b)
This patch SFINAE's away the function templates when the argument is
a basic_string.
On Fuchsia, pthread API is emulated on top of C11 thread API. Using C11
thread API directly is more efficient.
While this implementation is only used by Fuchsia at the moment, it's
not Fuchsia specific, and could be used by other platforms that use C11
threads rather than pthreads in the future.
Differential Revision: https://reviews.llvm.org/D64378
This also makes this function consistent with the rest of the
libc++ provided fallbacks.
The locale support in msvcrt.dll is very limited anyway; it can
only be configured processwide, not per thread, and it only seems
to support the locales "C" and "" (the user set locale), so it's
hard to make any meaningful automatic test for it. But manually tested,
this change does make time formatting locale code in libc++ output
times in the user requested format, when using locale "".
Differential Revision: https://reviews.llvm.org/D69554
The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.
This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.
Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.
(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.
Summary:
`__has_attribute(fallthough)` -> `__has_attribute(fallthrough)`
This is a follow-up of https://reviews.llvm.org/D72287
Reviewers: EricWF, mclow.lists, Jim
Reviewed By: Jim
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D72314
Add NetBSD to the same feature list as Fuchsia since it matches
in available features, effectively enabling aligned_alloc(),
timespec_get() and C11 features. Remove now-duplicate declaration
of quick_exit() support.
Differential Revision: https://reviews.llvm.org/D71511
This patch de-duplicates most compressed pair constructors
to use the same code in C++11 and C++03.
Part of doing that is deleting the "__second_tag()" and replacing
it with a "__value_init_tag()" which has the same effect, but
allows for the removal of the special "one-arg" first element
constructor.
This patch is intended to have no semantic change.
This change introduces the __default_init_tag to memory, and a corresponding
element constructor to allow for default initialization of either of the pair
values. This is useful for classes such as std::string where most (all)
constructors explicitly initialize the values in the constructor.
Patch by Martijn Vels (mvels@google.com)
Reviewed as https://reviews.llvm.org/D70617
Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.
In future, all warnings disabled for the test suite should require
an attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.
Since C++11, [depr.impldec]:
The implicit definition of a copy constructor as defaulted is deprecated
if the class has a user-declared copy assignment operator or a
user-declared destructor.
At clang HEAD, -Wdeprecated-copy (included by -Wextra) will warn on such instances.
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D71096
Android API level 21 and above have all these functions available, so we
don't need to include our fallback definitions.
Differential Revision: https://reviews.llvm.org/D69983
Summary:
Android added quick_exit()/at_quick_exit() in API level 21,
aligned_alloc() in API level 28, and timespec_get() in API level 29,
but has the other C11 features at all API levels (since they're basically
just coming from clang directly).
_LIBCPP_HAS_QUICK_EXIT and _LIBCPP_HAS_TIMESPEC_GET already existed,
so we can reuse them. (And use _LIBCPP_HAS_TIMESPEC_GET in a few more
places where _LIBCPP_HAS_C11_FEATURES has been used as a proxy. This
isn't correct for Android.)
_LIBCPP_HAS_ALIGNED_ALLOC is added, to cover aligned_alloc() (obviously).
Add a missing std:: before aligned_alloc in a cstdlib test, and remove a
couple of !defined(_WIN32)s now that we're explicitly testing
TEST_HAS_ALIGNED_ALLOC rather than TEST_HAS_C11_FEATURES.
Reviewers: danalbert, EricWF, mclow.lists
Reviewed By: danalbert
Subscribers: srhines, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69929
With the upcoming introduction of iterator concepts in ranges,
the meaning of "__is_contiguous_iterator" changes drastically.
Currently we intend it to mean "does it have this iterator category",
but it could now also mean "does it meet the requirements of this
concept", and these can be different.
These traits are currently unused because we don't implement ranges.
However, their addition is part of ongoing work to allow libc++
to optimize on user-provided contiguous iterators.
This function has the same behavior as the now-standand std::to_address.
Re-using the name makes the behavior more clear, and in the future it
will allow us to correctly get the raw pointer for user provided pointer
types.
We effectively never want to export that function, which is an
implementation detail of libc++. This was previously tried in
603715c66b and then reverted in 8335dd314f because it caused
linker warnings. These linker warnings should go away now that we
use internal_linkage instead of always_inline to implement per-TU
insulation.
This change would have warned about the bug found in D62451.
No unit tests since the exception should never throw.
Differential Revision: https://reviews.llvm.org/D62452
Same idea as the current algorithm, that is, add (half of the difference between a and b) to a.
But we use a different technique for computing the difference: we compute b - a into a pair of integers that are named "sign_bit" and "diff". We have to use a pair because subtracting two 32-bit integers produces a 33-bit result.
Computing half of that is a simple matter of shifting diff right by 1, and adding sign_bit shifted left by 31. llvm knows how to do that with one instruction: shld.
The only tricky part is that if the difference is odd and negative, then shifting it by one isn't the same as dividing it by two - shifting a negative one produces a negative one, for example. So there's one more adjustment: if the sign bit and the low bit of diff are one, we add one.
For a demonstration of the codegen difference, see https://godbolt.org/z/7ar3K9 , which also has a built-in test.
Differential Revision: https://reviews.llvm.org/D69459
PR13592 was caused by a problem in how to compiler implemented the
__is_convertible_to intrinsic. That problem, reported as PR13591,
was fixed back in 2012. We don't support such old versions of Clang
anyway, so we don't need the library workaround that had been added
to solve PR13592 (while waiting for the compiler fix).
Summary: This patch removes `shared_ptr::make_shared` as it is not part of the standard. This patch also adds __create_with_cntrl_block, which is a help function that can be used in std::allocate_shared and std::make_shared. This is the third patch (out of 4) from D66178.
Reviewers: EricWF, mclow.lists, ldionne
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68805
llvm-svn: 375504
Summary:
In D67316 we added `_LIBCPP_C_HAS_NO_GETS` to signal that the C library
does not provide `gets()`, and added a test for FreeBSD 13 or higher,
using the compiler-defined `__FreeBSD__` macro.
Unfortunately this did not work that well for FreeBSD's own CI process,
since the gcc compilers used for some architectures define `__FreeBSD__`
to match the build host, not the target.
Instead, we should use the `__FreeBSD_version` macro from the userland
header `<osreldate.h>`, which is more fine-grained. See also
<https://reviews.freebsd.org/D22034>.
Reviewers: EricWF, mclow.lists, emaste, ldionne
Reviewed By: emaste, ldionne
Subscribers: dexonsmith, bsdjhb, krytarowski, christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D69174
llvm-svn: 375340
Summary: The implementation of P1152R4 in Clang has resulted in some deprecation warnings appearing in the libc++ and libc++abi test suite. Fix or suppress these warnings.
Reviewers: mclow.lists, EricWF
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68879
llvm-svn: 375307
Summary: In my last patch (D67675) I forgot a few variadics. This patch removes the remaining make_shared and allocate_shared C++03 variadics.
Reviewers: ldionne, EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68000
llvm-svn: 373971
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
This was previously committed as r372778 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.
Reviewers: mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
llvm-svn: 373092
Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.
This was previously committed as r372777 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.
Reviewers: mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65161
llvm-svn: 372983
Users should only get the assert() macros if they explicitly include
them.
Found after switching from the GNU C++ stdlib to the LLVM C++ stdlib.
llvm-svn: 372963
This declaration was previously missing despite appearing in the
synopsis. Users are still required to include <ostream> to get the
definition of the streaming operator.
llvm-svn: 372909
This also reverts:
- r372778: [libc++] Implement LWG 3158
- r372782: [libc++] Try fixing tests that fail on GCC 5 and older
- r372787: Purge mentions of GCC 4 from the test suite
Reason: the change breaks compilation of LLVM with libc++, for details see
http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html
llvm-svn: 372832
Summary: As suggested by @ldionne in D66178, this patch removes C++03 variadics //only//. Following patches will apply more updates.
Reviewers: ldionne, EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits, ldionne
Tags: #libc
Differential Revision: https://reviews.llvm.org/D67675
llvm-svn: 372780
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
llvm-svn: 372778
Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65161
llvm-svn: 372777
std::condition_variable is currently implemented via
pthread_cond_timedwait() on systems that use pthread. This is
problematic, since that function waits by default on CLOCK_REALTIME
and libc++ does not provide any mechanism to change from this
default.
Due to this, regardless of if condition_variable::wait_until() is
called with a chrono::system_clock or chrono::steady_clock parameter,
condition_variable::wait_until() will wait using CLOCK_REALTIME. This
is not accurate to the C++ standard as calling
condition_variable::wait_until() with a chrono::steady_clock parameter
should use CLOCK_MONOTONIC.
This is particularly problematic because CLOCK_REALTIME is a bad
choice as it is subject to discontinuous time adjustments, that may
cause condition_variable::wait_until() to immediately timeout or wait
indefinitely.
This change fixes this issue with a new POSIX function,
pthread_cond_clockwait() proposed on
http://austingroupbugs.net/view.php?id=1216. The new function is
similar to pthread_cond_timedwait() with the addition of a clock
parameter that allows it to wait using either CLOCK_REALTIME or
CLOCK_MONOTONIC, thus allowing condition_variable::wait_until() to
wait using CLOCK_REALTIME for chrono::system_clock and CLOCK_MONOTONIC
for chrono::steady_clock.
pthread_cond_clockwait() is implemented in glibc (2.30 and later) and
Android's bionic (Android API version 30 and later).
This change additionally makes wait_for() and wait_until() with clocks
other than chrono::system_clock use CLOCK_MONOTONIC.<Paste>
llvm-svn: 372016
exceptions are disabled.
The patch was reverted due to some confusion about non-movable types. ie
types
that explicitly delete their move constructors. However, such types do
not meet
the requirement for `MoveConstructible`, which is required by
`std::vector`:
Summary:
`std::vector<T>` is free choose between using copy or move operations
when it
needs to resize. The standard only candidates that the correct exception
safety
guarantees are provided. When exceptions are disabled these guarantees
are
trivially satisfied. Meaning vector is free to optimize it's
implementation by
moving instead of copying.
This patch makes `std::vector` unconditionally move elements when
exceptions are
disabled. This optimization is conforming according to the current
standard wording.
There are concerns that moving in `-fno-noexceptions`mode will be a
surprise to
users. For example, a user may be surprised to find their code is slower
with
exceptions enabled than it is disabled. I'm sympathetic to this
surprised, but
I don't think it should block this optimization.
Reviewers: mclow.lists, ldionne, rsmith
Reviewed By: ldionne
Subscribers: zoecarver, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62228
llvm-svn: 371867
Summary:
In https://svnweb.freebsd.org/changeset/base/351659 @emaste removed gets() from
FreeBSD 13's libc, and our copies of libc++ and libstdc++. In that change, the
declarations were simply deleted, but I would like to propose this conditional
test instead.
Reviewers: EricWF, mclow.lists, emaste
Reviewed By: mclow.lists
Subscribers: krytarowski, christof, ldionne, emaste, libcxx-commits
Differential Revision: https://reviews.llvm.org/D67316
llvm-svn: 371324
This reverts r370502, which broke the use case of a copy-only T (with a
deleted move constructor) when exceptions are disabled. Until we figure
out the right behavior, I'm reverting the commit.
llvm-svn: 371068
This is needed anytime we need to clamp an arbitrary floating point
value to an integer type.
Thanks to Eric Fiselier for the patch.
Differential Revision: https://reviews.llvm.org/D66836
llvm-svn: 370891
An upcoming change in Clang will flag _Atomic as being a C11 extension.
To avoid generating this warning in libc++, this commit marks the only
use of _Atomic with the __extension__ extension, which suppresses such
warnings.
llvm-svn: 370796
Summary:
`std::vector<T>` is free choose between using copy or move operations when it needs to resize. The standard only candidates that the correct exception safety guarantees are provided. When exceptions are disabled these guarantees are trivially satisfied. Meaning vector is free to optimize it's implementation by moving instead of copying.
This patch makes `std::vector` unconditionally move elements when exceptions are disabled.
This optimization is conforming according to the current standard wording.
There are concerns that moving in `-fno-noexceptions`mode will be a surprise to users. For example, a user may be surprised to find their code is slower with exceptions enabled than it is disabled. I'm sympathetic to this surprised, but I don't think it should block this optimization.
Reviewers: mclow.lists, ldionne, rsmith
Reviewed By: ldionne
Subscribers: zoecarver, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62228
llvm-svn: 370502
Since we build the library with -fvisibility=hidden, the shared object
wouldn't contain __vector_base_common<true>::__throw_length_error()
and __vector_base_common<true>::__throw_out_of_range(), leading to
link errors. This only happened on GCC for some reason.
https://llvm.org/PR43140
llvm-svn: 370240
_LIBCPP_HAS_THREAD_API_EXTERNAL is not defined.
When it is defined they will be declared by the
__external_threading header instead.
Differential revision: https://reviews.llvm.org/D66518
llvm-svn: 369537
Summary:
The resolution of LWG 3199 makes sure that input-streaming into an empty bitset
does not set the failbit on the input stream.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65105
llvm-svn: 369422
A new clang warning introduced in r367497 was complaining about
the change in value.
Thanks to Brian Cain for the patch.
Differential Revision: https://reviews.llvm.org/D66422
llvm-svn: 369393
The commit being reverted caused segfaults when building
with libc++ and GCC (and possibly other configurations).
Differential Revision: https://reviews.llvm.org/D62868
llvm-svn: 369270
In r292833, we started defining _LIBCPP_CLANG_VER to 0 for Apple Clang.
The result is that AppleClang is detected as being a very old version
of LLVM Clang (version 0), which is obviously incorrect.
I believe this was added so that we don't have to check whether
_LIBCPP_CLANG_VER is defined prior to comparing it with a number
(which can trigger a warning). This commit also fixes the two
places that use the macro correspondingly.
llvm-svn: 368880
Summary:
This avoids symbols being accidentally exported from the dylib when they
shouldn't. The next step is to use a pragma to apply hidden visibility
to all declarations (unless otherwise specified), which will allow us
to drop the per-declaration hidden visibility attributes we currently
have.
This also has the nice side effect of making sure the dylib exports the
same symbols regardless of the optimization level.
PR38138
Reviewers: EricWF, mclow.lists
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62868
llvm-svn: 368703
Summary:
D64914 added support for applying [[nodiscard]] to constructors. This
commit uses that capability to flag incorrect uses of std::lock_guard
where one forgets to actually create a variable for the lock_guard.
rdar://45790820
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, Quuxplusone, lebedev.ri
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65900
llvm-svn: 368664
Summary:
We were using implicit deduction guides instead of explicit ones,
however the implicit ones don't do work anymore when changing the
constructors.
This commit adds the actual guides specified in the Standard to make
libc++ (1) closer to the Standard and (2) more resistent to changes
in std::tuple's constructors.
Reviewers: Quuxplusone
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65225
llvm-svn: 368599
This patch rewrites a few loops in deque and split_buffer to better
optimize the codegen. For constructors like
`deque<unsigned char> d(500000, 0);` this patch results in a 2x speedup.
The patch improves the codegen in roughly three ways:
1. Changes do { ... } while (...) loops into more typical for loops.
The optimizer can reason about normal looking loops better.
2. Split the iteration over a range into (A) iteration over the blocks,
then (B) iteration within the block. This nested structure helps LLVM
lower the inner loop to `memset`.
3. Do fewer things each iteration. Some of these loops were incrementing
or changing 4-5 variables every loop (in addition to the
construction). Previously most loops would increment the end pointer,
the size, and decrement the count of remaining items to construct.
Now we only increment a single pointer for most iterations.
llvm-svn: 368547
For the few (currently four) headers that make up the PSTL's interface
to other Standard Libraries, provide a stable uglified header file that
can be included by those Standard Libraries.
We can then more easily change the internal organization of the PSTL
without having to change the integration with Standard Libraries.
llvm-svn: 368088
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 367903
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
llvm-svn: 367770
This patch rewrites a number of old meta-function implementations
that assumed const/volatile could not be safely applied to all types.
This is no longer the case, though for some types (Ex function types),
the const qualifier can be ignored.
The largest improvement in this patch is the reduction of is_function.
Thanks to Matt Calabrese for the improved implementation.
llvm-svn: 367749
I have upcoming changes that modify how deque handles spare blocks.
This cleanup is intended to make those changes easier to review
and understand. This patch should have NFC.
llvm-svn: 367631
Previously these types rehashed to a table of 193 elements
upon construction. But this is non-ideal, first because default
constructors should not allocate unless necessary, and second
because 193 is big and can waste a bunch of memory.
This number had previously been chosen to match GCC's implementation.
llvm-svn: 367605
[cpp.predefined]p2:
__STDCPP_THREADS__
Defined, and has the value integer literal 1, if and only if a program
can have more than one thread of execution .
Also define it only if it's not defined already, since it's supposed
to be defined by the compiler.
Also move it from thread to __config (which requires setting it only
if _LIBCPP_HAS_NO_THREADS is not defined).
Part of PR33230. The intent is to eventually make the compiler define
this instead.
llvm-svn: 367316
The optimizer is petulant and temperamental. In this case LLVM failed to lower
the the "insert at end" loop used by`vector<unsigned char>` to a `memset` despite
`memset` being substantially faster over a range of bytes.
LLVM has the ability to lower loops to `memset` whet appropriate, but the
odd nature of libc++'s loops prevented the optimization from taking places.
This patch addresses the issue by rewriting the loops from the form
`do [ ... --__n; } while (__n > 0);` to instead use a for loop over a pointer
range (For example: `for (auto *__i = ...; __i < __e; ++__i)`).
This patch also rewrites the asan annotations to unposion all additional memory
at the start of the loop instead of once per iterations. This could potentially
permit false negatives where the constructor of element N attempts to access
element N + 1 during its construction.
The before and after results for the `BM_ConstructSize/vector_byte/5140480_mean`
benchmark (run 5 times) are:
--------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------------------------------
Before
------
BM_ConstructSize/vector_byte/5140480_mean 12530140 ns 12469693 ns N/A
BM_ConstructSize/vector_byte/5140480_median 12512818 ns 12445571 ns N/A
BM_ConstructSize/vector_byte/5140480_stddev 106224 ns 107907 ns 5
-----
After
-----
BM_ConstructSize/vector_byte/5140480_mean 167285 ns 166500 ns N/A
BM_ConstructSize/vector_byte/5140480_median 166749 ns 166069 ns N/A
BM_ConstructSize/vector_byte/5140480_stddev 3242 ns 3184 ns 5
llvm-svn: 367183
The constructors for std::pair and std::tuple have been made conditionally
explicit, however the synopsis in the headers do not reflect that.
llvm-svn: 366735
This issue was detected by ASan in one of our tests. This test manually
invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero
exit status, so __file_ wasn't set to 0. Later when basic_filebuf
destructor ran, we would enter the if (__file_) block again leading to
heap-use-after-free error.
The POSIX specification for fclose says that independently of the return
value, fclose closes the underlying file descriptor and any further
access (including another call to fclose()) to the stream results in
undefined behavior. This is exactly what happened in our test case.
To avoid this issue, we have to always set __file_ to 0 independently of
the fclose return value.
Differential Revision: https://reviews.llvm.org/D64979
llvm-svn: 366730
This reverts r366593, which caused unforeseen breakage on the build bots.
I'm reverting until the problems have been figured out and fixed.
llvm-svn: 366603
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
Reviewers: rodgert, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 366593
Summary:
This is effectively a revert of r344616, which was a partial fix for
PR38964 (compilation of <string> with GCC in C++03 mode). However, that
configuration is explicitly not supported anymore and that partial fix
breaks compilation with Clang when per-TU insulation is provided.
PR42676
rdar://52899715
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64941
llvm-svn: 366567
In particular, improve the compile time of the overload set builder
that variant uses to determine which alternative to construct.
Instead of having the __overload type construct itself recursively,
this patch uses a flat construction for the overload set.
llvm-svn: 366033
The standard disallows narrowing conversions when constructing a variant.
This is checked by attempting to perform braced initialization of the
destination type from the argument type. However, braced initialization
can force the compiler (mostly clang) to eagerly instantiate the
constructors of the destintation type -- which can lead to errors in
a non-immediate context.
However, as variant is currently specified, the narrowing checks only
observably apply when the destination type is arithmetic. Meaning we can
skip the check for class types. Hense avoiding the hard errors.
In order to cause fewer build breakages, this patch avoids the narrowing
check except when the destination type is arithmetic.
llvm-svn: 366022
Previously we implemented all one trillion tuple-like constructors using
a single generic overload. This worked fairly well, except that it
differed in behavior from the standard version because it didn't
consider both T&& and T const&. This was observable for certain
types.
This patch addresses that issue by splitting the generic constructor
in two. We now provide both T&& and T const& versions of the
tuple-like constructors (sort of).
llvm-svn: 365973
The paper P0608R3 - "A sane variant converting constructor" disallows
narrowing conversions in variant. It was meant to address this
surprising problem:
std::variant<std::string, bool> v = "abc";
assert(v.index() == 1); // constructs a bool.
However, it also disables every potentially narrowing conversion. For
example:
variant<unsigned> v = 0; // ill-formed
variant<string, double> v2 = 42; // ill-formed (int -> double narrows)
These latter changes break code. A lot of code. Within Google it broke
on the order of a hundred thousand target with thousands of root causes
responsible for the breakages.
Of the breakages related to the narrowing restrictions, none of them
exposed outstanding bugs. However, the breakages caused by boolean
conversions (~13 root causes), all but one of them were bugs.
For this reasons, I am adding a flag to disable the narrowing conversion
changes but not the boolean conversions one.
One purpose of this flag is to allow users to opt-out of breaking changes
in variant until the offending code can be cleaned up. For non-trivial
variant usages the amount of cleanup may be significant.
This flag is also required to support automated tooling, such as
clang-tidy, that can automatically fix code broken by this change.
In order for clang-tidy to know the correct alternative to construct,
it must know what alternative was being constructed previously, which
means running it over the old version of std::variant.
Because this change breaks so much code, I will be implementing the
aforementioned clang-tidy check in the very near future.
Additionally I'm plan present this new information to the committee so they can
re-consider if this is a breaking change we want to make.
I think libc++ should very seriously consider pulling this change
before the 9.0 release branch is cut. But that's a separate discussion
that I will start on the lists.
For now this is the minimal first step.
llvm-svn: 365960
When assigning an initializer list into set/map, libc++ would
leak memory if the initializer list contained equivalent keys
because we failed to check if the insertion was successful.
llvm-svn: 365840
The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy
are already NOPs, so this optimization is safe to perform.
See r365273 and PR27658 for more information.
llvm-svn: 365281
Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.
The constexpr constructor is required to ensure the construction of a
mutex with static storage duration happens at compile time, during
constant initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used
safely during dynamic initialization without the "static initialization
order fiasco".
A trivial destructor is important for similar reasons. If a mutex is
used during dynamic initialization it might also be used during program
termination. If a static mutex has a non-trivial destructor it will be
invoked during termination. This can introduce the "static
deinitialization order fiasco".
Additionally, function-local statics emit a guard variable around
non-trivially destructible types. This results in horrible codegen and
adds a runtime cost to every call to that function. non-local static's
also result in slightly worse codegen but it's not as big of a problem.
Example codegen can be found here: https://goo.gl/3CSzbM
Note: This optimization is not safe with every pthread implementation.
Some implementations allocate on the first call to pthread_mutex_lock
and free the allocation in pthread_mutex_destroy.
Also, changing the triviality of the destructor is not an ABI break.
At least to the best of my knowledge :-)
llvm-svn: 365273
types.
It seems some people like to write types that can explicitly convert
to anything, but cannot be used to explicitly construct anything.
This patch makes tuple tolerate such types, as is required
by the standard.
llvm-svn: 365074
Summary:
This fixes a clang-tidy warning when building something that uses
this file.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43226
llvm-svn: 364799
when _LIBCPP_ABI_UNSTABLE is defined.
User defined _LIBCPP_ABI_NAMESPACE will still be respected,
but the default version namespace in unstable mode will be the libc++ version
(Currently '__9000').
Previously `_LIBCPP_ABI_VERSION` and `_LIBCPP_ABI_NAMESPACE` were
`1` and `__1` respectively, whuch conflicted with the stable ABI
llvm-svn: 364354
The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use the new ones.
llvm-svn: 364160
Clang provides __is_same that doesn't produce any instantiations
and just returns a bool. It's a lot faster than using std::is_same
I'll follow up with a patch to actually start using it.
llvm-svn: 364148
The CMake CheckLibcxxAtomic module was always failing to compile
the example, even when libatomic wasn't needed. This was caused
because the check doesn't link a C++ runtime library to provide
std::terminate, which is required for exception support.
The check is still really broken, but <atomic> is better!
llvm-svn: 364146
Using class templates instead of alias templates causes a lot of
instantiations. As part of the move away from C++03, we want to
improve the efficiency of our meta-programming.
This patch lays the groundwork by introducing new _If, _EnableIf,
_And, _Or, and _IsValidExpansion (detect member). Future patches
will replace the existing implementations after verifying there
compile time differences.
llvm-svn: 364114
These functions are key to allowing the use of rvalues and variadics
in C++03 mode. Everything works the same as in C++11, except for one
tangentially related case:
struct T {
T(T &&) = default;
};
In C++11, T has a deleted copy constructor. But in C++03 Clang gives
it both a move and a copy constructor. This seems reasonable enough
given the extensions it's using.
The other changes in this patch were the minimal set required
to keep the tests passing after the move/forward change. Most notably
the removal of the `__rv<unique_ptr>` hack that was present
in an attempt to make unique_ptr move only without language support.
llvm-svn: 364063
All the compilers we support provide these builtins. We don't
need to do a configuration dance anymore.
This patch also cleans up some dead or almost dead
C++11 feature detection macros.
llvm-svn: 364047
Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, this might
cause problems for platforms with external thread porting layer (i.e.
when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11
C libraries.
In our downstream port of libc++ we used to provide a definition of
timespec in __external_threading, but this solution is not ideal
because timespec is not a reserved name.
This patch renames timespec into __libcpp_timespec_t in the
thread-related parts of libc++. For all cases except external
threading this type is an alias for ::timespec (and no functional
changes are intended).
In case of external threading it is expected that the
__external_threading header will either provide a similar typedef (if
timespec is available in the vendor's C library) or provide a
definition of __libcpp_timespec_t compatible with POSIX timespec.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne
Subscribers: dexonsmith, libcxx-commits, christof, carwil
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63328
llvm-svn: 364012
This is a re-application of r362986 (which was reverted in r363688) with fixes
for the issue that caused it to be reverted.
Thanks to Arthur O'Dwyer for the patch.
Differential Revision: https://reviews.llvm.org/D58587
llvm-svn: 363968
Summary:
AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined so that limit macro definitions such as UINT32_MAX can be found. This patch attempts to allow that on AIX.
Reviewers: hubert.reinterpretcast, jasonliu, mclow.lists, EricWF
Reviewed by: hubert.reinterpretcast, mclow.lists
Subscribers: jfb, jsji, christof, cfe-commits, libcxx-commits, llvm-commits
Tags: #LLVM, #clang, #libc++
Differential Revision: https://reviews.llvm.org/D59253
llvm-svn: 363939
This was found to be broken on Clang trunk. This is a revert of the
following commits (the subsequent commits added XFAILs to the tests
that were missing from the original submission):
r362986: Implement deduction guides for map/multimap.
r363014: Add some XFAILs
r363097: Add more XFAILs
r363197: Add even more XFAILs
llvm-svn: 363688
Summary:
The class ctype_base in the header <__locale> contains masks for
character classification functions, which are kept in sync with
platform's C library, hence it contains many special cases.
The value of the bit mask __regex_word in the header <regex> must not
clash with those bit masks.
Currently the default case (i.e. unknown platform/C library) is
handled incorrectly: the __regex_word clashes with ctype_base::punct.
To avoid replicating the whole list of platforms in <regex> this patch
defines __regex_word in <__locale>, so that it is always kept in sync
with other masks.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne
Subscribers: krytarowski, christof, dexonsmith, pbarrio, simon_tatham, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63284
llvm-svn: 363363
Summary:
This patch make G++03 explicitly unsupported with libc++, as discussed on the mailing lists.
Below is the rational for this decision.
----------------------------------------------------------------------------------------------------
libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users.
Our C++03 users are all using Clang. They must be. Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.
Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could::
* Improve Correctness:
Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics.
* Achieve ABI stability between C++03 and C++11
Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed.
* Decrease Compile Times and Memory Usage:
Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially.
* Decrease Binary Size
Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne, EricWF
Subscribers: zoecarver, aprantl, dexonsmith, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D63154
llvm-svn: 363219
When applied to a typedef or alias template, the [[nodebug]] attribute
makes the typedef transparent to the debugger, so instead of seeing
`std::__function::__alloc_func<remove_reference<void(&)()>::type,
allocator<remove_reference<void(&)()>, void()>::_Target` you see
`void(&)()` as the type of the variable in your debugger.
Removing all this SFINAE noise from debug info has huge binary size
wins, in addition to improving the readability.
For now this change is on by default. Users can override it by
specifying -D_LIBCPP_NODEBUG_TYPE=
llvm-svn: 363117
Summary:
This is not mandated by the Standard, but it's nonetheless a nice
property to have, especially since it's so easy to implement. It
also shrinks our bug list!
PR41714
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62618
llvm-svn: 363075
Summary:
Following the discussion on the libcxx-dev mailing list
(http://lists.llvm.org/pipermail/libcxx-dev/2019-May/000358.html),
this implements the new policy for handling experimental features and
their deprecation. We basically add a deprecation warning for
std::experimental::filesystem, and we remove a bunch of <experimental/*>
headers that were now empty.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits, jfb
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62428
llvm-svn: 363072
std::function uses a standard allocator to manage its memory, however
standard allocators are templates and using them correctly requires
a stupid amount of instantiations. This leads to a substantial increase
in debug info and object sizes.
This patch addresses the issue by dropping the allocator when possible
and using raw new and delete to get memory.
This change decreases the object file size for the test func.wrap.func.con/F.pass.cpp by 33% and the final binary by 29% (when compiled with -g -ggnu-pubnames -gpubnames).
It also roughly halfs the number of entries in the pubnames and pubtype
sections.
llvm-svn: 362865
merged type info names.
Previously std::type_info always expected type info string to be unique.
But this isn't always the case. Like when -Bsymbolic is passed to the
linker or due to llvm.org/PR37398.
This patch adds the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake
option which, when specified, overrides the default configuration for
the library.
The current defaults still assume unique names even though this isn't
strictly correct for ELF binaries. We should consider changing the
default in a follow up commit.
llvm-svn: 361913
Summary:
This provides the `std::destroying_delete_t` declaration in C++2a and after. (Even when the compiler doesn't support the language feature).
However, the feature test macro `__cpp_lib_destroying_delete` is only defined when we have both language support and C++2a.
Reviewers: ldionne, ckennelly, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: dexonsmith, riccibruno, christof, jwakely, jdoerfert, mclow.lists, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55840
llvm-svn: 361572
Summary: On some platforms C++ headers are packaged with the compiler not the sysroot. If you don't copy C++ headers into the build include directory during configuraiton of the outer build the C++ check during the runtime configuration may get inaccurate results.
Reviewers: phosek, compnerd, smeenai, EricWF
Reviewed By: compnerd
Subscribers: EricWF, christof, libcxx-commits, mgorny, llvm-commits
Tags: #llvm, #libc
Differential Revision: https://reviews.llvm.org/D62155
llvm-svn: 361513
The `using namespace std;` opens us up to ambiguity
when any of the std:: names are also present in the global namespace.
Instead we should properly qualify names we use from std::.
llvm-svn: 361074
This adds explicit support for the WASI platform to libcxx.
WASI libc uses some components from musl, however it's not fully compatible
with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and
customize for WASI libc specifically.
Differential Revision: https://reviews.llvm.org/D61336
Reviewers: sbc100, ldionne
llvm-svn: 359703
Summary:
The current implementation of aligned storage was written before we had `alignas`, so it used a list of builtin types to force the alignment. But this doesn't work overaligned requests.
This patch adds a fallback case supporting over-alignment. It only affects case that were previously ill-formed.
Reviewers: rsmith, ldionne, dlj, mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D61301
llvm-svn: 359596
When the arguments to tuple cat were const, the const was incorrectly
propagated into the type of the resulting tuple. For example:
const std::tuple<int> t(42);
auto r = std::tuple_cat(t, t);
// Incorrect! should be std::tuple<int, int>.
static_assert(is_same_v<decltype(r), std::tuple<const int, const int>>);
llvm-svn: 359255
libc++ ABI v1 provides three valarray symbols as part of the shared library:
valarray<size_t>::valarray(size_t)
valarray<size_t>::~valarray()
valarray<size_t>::resize(size_t, size_t)
The first two of these are intended to be removed in V2 of the ABI: they're
attributed _LIBCPP_HIDE_FROM_ABI_AFTER_V1, and it appears that the intention
is that these symbols from the library are not used even when building using
the V1 ABI. However, there are explicit instantiation declarations for all
three symbols in the header, which are not correct as we do not intend to find
an instantiation of these functions that is provided elsewhere.
(A recent change to clang to properly diagnose explicit instantiation
declarations of internal linkage functions -- required by [temp.explicit]p13 --
had to be rolled back because it diagnosed these explicit instantiations.)
Remove the explicit instantiation declarations, and remove the explicit
instantiation definitions for V2 of the libc++ ABI onwards.
llvm-svn: 359243
std::mutex was not actually is_nothrow_default_constructible in C++98/C++03,
because the variable declaration
std::mutex M;
... could throw an exception from the mutex destructor. Fix it by marking the
destructor as non-throwing. This has no effect in C++11 onwards, because
destructors are non-throwing by default in those language modes.
llvm-svn: 359229
Contrary to MSVC, MinGW compilers wants the dllexport attribute on
the declaration of an explicit template instantiation, not on the
definition.
Differential Revision: https://reviews.llvm.org/D61123
llvm-svn: 359227
Teach libcxx to stop using various deprecated __has_* type traits, in favor of
the ("modern", C++11 era) __is_* type traits.
This is mostly just a simplification, but fixes at least one bug: _Atomic T
should be considered trivially-destructible, but is not considered to be POD by
Clang, and __has_trivial_destructor is specified in the GCC documentation as
returning false for non-POD non-class types.
Differential Revision: https://reviews.llvm.org/D48292
llvm-svn: 359159
Summary:
All overloads of `::abs` and `std::abs` must be present in both `<cmath>` and `<cstdlib>`. This is problematic to implement because C defines `fabs` in `math.h` and `labs` in `stdlib.h`. This introduces a circular dependency between the two headers.
This patch implements that requirement by moving `abs` into `math.h` and making `stdlib.h` include `math.h`. In order to get the underlying C declarations from the "real" `stdlib.h` inside our `math.h` we need some trickery. Specifically we need to make `stdlib.h` include next itself.
Suggestions for a cleaner implementation are welcome.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: krytarowski, fedor.sergeev, dexonsmith, jdoerfert, jsji, libcxx-commits
Differential Revision: https://reviews.llvm.org/D60097
llvm-svn: 359020
This is a followup to [1] which added a new `__debug_less::operator()` overload.
[2] added `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the original
`__debug_less::operator()` between the time of writing [1] and landing it. This
change adds `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the new overload too.
[1] https://reviews.llvm.org/rL358423
[2] https://reviews.llvm.org/rL358252
Differential Revision: https://reviews.llvm.org/D60724
llvm-svn: 358725
This used to be guarded on whether the deployment target was greater
than macosx10.8, however testing against the dylibs for 10.8 and earlier
with the function enabled works too. The revision that introduced
__pad_and_output is r164241 and it does not mention a reason for the
guard.
llvm-svn: 358677
Summary:
Otherwise, we can run into problems when the program has static variables
that need to use the debug database during their deinitialization, if
the debug DB has already been deinitialized.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60830
llvm-svn: 358602
There are many STL algorithms (such as lexicographical_compare) that compare
values pointed to by iterators like so:
__comp(*it1, *it2);
When building with `_LIBCPP_DEBUG=0`, comparators are wrapped in `__debug_less`
which does some additional validation. But `__debug_less::operator()` takes
non-const references, so if the type of `*it1` is int, not int&, then the build
will fail.
This change adds a `const&` overload for `operator()` to fix the build.
Differential Revision: https://reviews.llvm.org/D60592
llvm-svn: 358423
Instead of having an `#if` block in every algorithm using a debug
comparator, this patch introduces the __comp_ref_type trait that
selects __debug_less in debug mode and _Comp& otherwise.
This patch should have no observable functionality change.
llvm-svn: 358252
Summary:
In r348529, I improved the library-defined diagnostic for using containers
with a non-const comparator/hasher. However, the check is now performed
too early, which leads to the diagnostic being emitted in cases where it
shouldn't. See PR41360 for details.
This patch moves the diagnostic to the destructor of the containers, which
means that the diagnostic will only be emitted when the container is instantiated
at a point where the comparator and the key/value are required to be complete.
We still retain better diagnostics than before r348529, because the diagnostics
are performed in the containers themselves instead of __tree and __hash_table.
As a drive-by fix, I improved the diagnostic to mention that we can't find
a _viable_ const call operator, as suggested by EricWF in PR41360.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, zoecarver
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60540
llvm-svn: 358189
Harald van Dijk