-Wc++11-narrowing warning on Darwin
The internal CI produced the following diagnostic:
error: non-constant-expression cannot be narrowed from type 'long long' to '__darwin_suseconds_t' (aka 'int') in initializer list [-Wc++11-narrowing]
struct ::timeval ConvertedTS[2] = {{TS[0].tv_sec, Convert(TS[0].tv_nsec)},
^~~~~~~~~~~~~~~~~~~~~~
llvm-svn: 337968
Patch by Victor Zverovich.
This fixes an error when compiling `<experimental/filesystem>` with gcc 4.8.5:
```
.../libcxx/src/experimental/filesystem/filesystem_common.h:137:34:
error: redeclaration ‘T
std::experimental::filesystem::v1::detail::{anonymous}::error_value() [with T =
bool]’ d
iffers in ‘constexpr’
constexpr bool error_value<bool>() {
^
.../libcxx/src/experimental/filesystem/filesystem_common.h:133:3:
error: from previous declaration ‘T
std::experimental::filesystem::v1::detail::{anonymous}::error_value() [with T
= bool]’
T error_value();
^
```
Reviewed as https://reviews.llvm.org/D49813
llvm-svn: 337962
Summary:
The ``file_time_type`` time point is used to represent the write times for files.
Its job is to act as part of a C++ wrapper for less ideal system interfaces. The
underlying filesystem uses the ``timespec`` struct for the same purpose.
However, the initial implementation of ``file_time_type`` could not represent
either the range or resolution of ``timespec``, making it unsuitable. Fixing
this requires an implementation which uses more than 64 bits to store the
time point.
I primarily considered two solutions: Using ``__int128_t`` and using a
arithmetic emulation of ``timespec``. Each has its pros and cons, and both
come with more than one complication.
However, after a lot of consideration, I decided on using `__int128_t`. This patch implements that change.
Please see the [FileTimeType Design Document](http://libcxx.llvm.org/docs/DesignDocs/FileTimeType.html) for more information.
Reviewers: mclow.lists, ldionne, joerg, arthur.j.odwyer, EricWF
Reviewed By: EricWF
Subscribers: christof, K-ballo, cfe-commits, BillyONeal
Differential Revision: https://reviews.llvm.org/D49774
llvm-svn: 337960
Summary:
The exact same code was replicated 11 times for implementing the basic_istream
input operators (those that don't use numeric_limits). The same code was also
duplicated twice for implementing the basic_istream input operators that take
numeric_limits into account.
This commit factors the common code into function templates to avoid
the duplication.
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49808
llvm-svn: 337955
This fixes a warning like this:
warning: comparison of integers of different signs:
'std::__1::__libcpp_tls_key' (aka 'long') and 'DWORD'
(aka 'unsigned long') [-Wsign-compare]
if (*__key == FLS_OUT_OF_INDEXES)
~~~~~~ ^ ~~~~~~~~~~~~~~~~~~
Differential Revision: https://reviews.llvm.org/D49782
llvm-svn: 337946
Tuple has tests that ensure we diagnose non-lifetime extended
reference bindings inside tuples constructors. As of yesterday,
Clang now does this for us.
Adjust the test to tolerate the new diagnostics, while still
testing that we emit diagnostics of our own. Maybe after this
version of Clang has been adopted by most users we should
remove our diagnostics; but for now more error detection is
better!
llvm-svn: 337905
Libc++ was incorrectly reporting an error when the target of create_directory
already exists, but was not a directory. This behavior is not specified
in the most recent standard, which says no error should be reported.
Additionally, libc++ failed to report an error when the attribute directory
path didn't exist or didn't name a directory. This has been fixed as well.
Although it's not clear if we should call status or symlink_status on the
attribute directory. This patch chooses to still call status.
llvm-svn: 337888
Previously the <experimental/filesystem> didn't guard its
contents in any dialect. However, the implementation implicitly
requires at least C++11, and the tests have always been marked
unsupported in C++03. This patch puts a header guard around the
contents to avoid exposing them before C++11.
Additionally, it replaces all of the usages of _NOEXCEPT or
_LIBCPP_CONSTEXPR with the keyword directly, since we can
expect the compiler to implement those by now.
llvm-svn: 337884
To avoid exposing implementation details, path::iterator and PathParser
both implicitly used the same set of values to represent the state,
but they were defined twice. This could have lead to a mismatch
occuring.
This patch moves all of the parser state values into the filesystem
header and changes PathParser to use those value to avoid this.
llvm-svn: 337883
In upcoming changes to filesystem I plan to change file_time_type
to use __int128_t as its underlying representation, in order
to allow it to have a range and resolution at least that of
the timespec struct.
There was some pushback against this decision, so I drafted
a document explaining the problems, potential solutions, and
the rational for the decision.
However, it's probably easier to let people read the generated
HTML rather than the raw restructured text. For this reason
I'm commiting the design documents before hand, so they can
be available during any subsequent discussion or code review.
llvm-svn: 337880
Currently it's only possible to control whether shared or static library
build of libc++, libc++abi and libunwind is enabled or disabled and
whether to install everything we've built or not. However, it'd be
useful to have more fine grained control, e.g. when static libraries are
merged together into libc++.a we don't need to install libc++abi.a and
libunwind.a. This change adds this option.
Differential Revision: https://reviews.llvm.org/D49573
llvm-svn: 337867
This is an alternative approach to r337727 which broke the build
because libc++ headers were copied into the location outside of
directories used by Clang. This change sets LIBCXX_HEADER_DIR to
different values depending on whether libc++ is being built as
part of LLVM w/ per-target multiarch runtime, LLVM or standalone.
Differential Revision: https://reviews.llvm.org/D49711
llvm-svn: 337833
Summary:
This is not guaranteed to work since the characters after '__has_include('
have special lexing rules that can't possibly be applied when
__has_include is generated by a macro. It also breaks the crash reproducers
generated by -frewrite-includes (see https://llvm.org/pr37990).
Reviewers: EricWF, rsmith, mclow.lists
Reviewed By: mclow.lists
Differential Revision: https://reviews.llvm.org/D49067
llvm-svn: 337824
Unlike stat and lstat, where unknown really means we know it's something weird,
during directory iteration DT_UNKNOWN simply means that the underlying FS doesn't
support the dirent::dt_type field.
This patch fixes libc++ to correctly set the cache to empty when DT_UNKNOWN is reported.
llvm-svn: 337768
The initial patch didn't correctly handle systems when the dirent struct
didn't provide the d_type member. Specifically it set the cache to the incorrect state,
and claimed it was partially populated.
The updated version of this change correctly handles setting up the
cache when the file type is not known (aka file_type::none).
llvm-svn: 337765
When adding the new tests for the filesystem_error::what method,
I incorrectly removed a test case and replaced it with something else.
This patch restores that test case
llvm-svn: 337764
In most cases there is no reason why the filesystem internals
use the qualifier std:: or _VSTD::. This patch removes the unneeded
qualifiers, making the sources files more consistent
llvm-svn: 337684
Currently it's possible to select whether to statically link unwinder
or the C++ ABI library, but this option applies to both the shared
and static library. However, in some scenarios it may be desirable to
only statically link unwinder and C++ ABI library into static C++
library since for shared C++ library we can rely on dynamic linking
and linker scripts. This change enables selectively enabling or
disabling statically linking only to shared or static library.
Differential Revision: https://reviews.llvm.org/D49502
llvm-svn: 337668
This patch implements the `what()` for filesystem errors. The message
includes the 'what_arg', any paths that were specified, and the
error code message.
Additionally this patch refactors how errors are created, making it easier
to report them correctly.
llvm-svn: 337664
For some reason GCC ToT is failing to deduce the auto type for
a static data member from its initializer in some cases.
Though I'm sure the bug will be short lived, there is a trivial workaround for it.
So we might as well get the bot passing again.
llvm-svn: 337661
This patch removes the O_CREAT open flag when we first
attempt to open the destination file but we expect it to
already exist.
This theoretically avoids the possibility that it was removed
between when we first stat'ed it, and when we attempt to open it.
llvm-svn: 337659
This patch improves both the performance, and the safety of the
copy_file implementation.
The performance improvements are achieved by using sendfile on
Linux and copyfile on OS X when available.
The TOCTOU hardening is achieved by opening the source and
destination files and then using fstat to check their attributes to
see if we can copy them.
Unfortunately for the destination file, there is no way to open
it without accidentally creating it, so we first have to use
stat to determine if it exists, and if we should copy to it.
Then, once we're sure we should try to copy, we open the dest
file and ensure it names the same entity we previously stat'ed.
llvm-svn: 337649
This is a follow-up to r335809 and r337118. While libc++ headers are now
installed into the right location in both standard as well as multiarch
runtimes layout, turned out C++ ABI headers are still installed into the
old location in the latter case. This change addresses that.
Differential Revision: https://reviews.llvm.org/D49584
llvm-svn: 337630
First, <experimental/filesystem> didn't correctly guard
against min/max macros. This adds the proper push/pop macro guards.
Second, an internal time helper had been renamed but the test for
it hadn't been updated. This patch updates those tests.
llvm-svn: 337520
Summary:
This patch implements directory_entry caching *almost* as specified in P0317r1. However, I explicitly chose to deviate from the standard as I'll explain below.
The approach I decided to take is a fully caching one. When `refresh()` is called, the cache is populated by calls to `stat` and `lstat` as needed.
During directory iteration the cache is only populated with the `file_type` as reported by `readdir`.
The cache can be in the following states:
* `_Empty`: There is nothing in the cache (likely due to an error)
* `_IterSymlink`: Created by directory iteration when we walk onto a symlink only the symlink file type is known.
* `_IterNonSymlink`: Created by directory iteration when we walk onto a non-symlink. Both the regular file type and symlink file type are known.
* `_RefreshSymlink` and `_RefreshNonSymlink`: A full cache created by `refresh()`. This case includes dead symlinks.
* `_RefreshSymlinkUnresolved`: A partial cache created by refresh when we fail to resolve the file pointed to by a symlink (likely due to permissions). Symlink attributes are cached, but attributes about the linked entity are not.
As mentioned, this implementation purposefully deviates from the standard. According to some readings of the specification, and the Windows filesystem implementation, the constructors and modifiers which don't pass an `error_code` must throw when the `directory_entry` points to a entity which doesn't exist. or when attribute resolution fails for another reason.
@BillyONeal has proposed a more reasonable set of requirements, where modifiers other than refresh ignore errors. This is the behavior libc++ currently implements, with the expectation some form of the new language will be accepted into the standard.
Some additional semantics which differ from the Windows implementation:
1. `refresh` will not throw when the entry doesn't exist. In this case we can still meet the functions specification, so we don't treat it as an error.
2. We don't clear the path name when a constructor fails via refresh (this will hopefully be changed in the standard as well).
It should be noted that libstdc++'s current implementation has the same behavior as libc++, except for point (2).
If the changes to the specification don't get accepted, we'll be able to make the changes later.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html
Reviewers: mclow.lists, gromer, ldionne, aaron.ballman
Subscribers: BillyONeal, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D49530
llvm-svn: 337516
Summary:
Currently, the ABI list test only works for ABI version 1. This commit
allows running the ABI list test with ABI version 2. It also adds an
ABI list file for ABI v2 on Mac OS X.
Reviewers: EricWF
Subscribers: mgorny, christof, dexonsmith, llvm-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D49509
llvm-svn: 337477
When an always_inline function is used prior to the functions definition,
the compiler may not be able to inline it as requested by the attribute.
GCC flags the `basic_string(CharT const*)` function as one such example.
This patch supresses the warning, and the problem, by moving the
definition of the string constructor to the inline declaration.
This ensures the body is available when it is first ODR used.
llvm-svn: 337235
This patch guards the use of __attribute__((init_priority(101)))
within memory_resource.cpp when building with compilers that don't
support it. Specifically GCC on Apple platforms, and MSVC.
llvm-svn: 337205
This variable is already set in CMakeLists.txt but it wasn't used
which means that the headers get installed into a wrong location
when the per target runtime directory option is being used.
Differential Revision: https://reviews.llvm.org/D49345
llvm-svn: 337118
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, erikvanderpoel
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336866
Do not use LLVM_RUNTIMES_LIBDIR_SUFFIX variable which is an internal
variable used by the runtimes build from individual runtimes, instead
set per-runtime librarhy directory suffix variable which is necessary
for the sanitized runtimes build to install libraries into correct
location.
Differential Revision: https://reviews.llvm.org/D49121
llvm-svn: 336713
Summary:
It was defined with the right visibility, but declared without any visibility.
This function was left out of a prior revision that did the same to several
functions in <compare> (r336665) because the compiler I used didn't support
coroutines. This reinforces the need for automated checks -- there might
still be several cases of this throughout the library.
Reviewers: EricWF
Subscribers: modocache, christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D49145
llvm-svn: 336709
Summary:
Many operators in <compare> were _defined_ with the proper visibility attribute,
but they were _declared_ without any. This is not a problem until we change the
definition of _LIBCPP_INLINE_VISIBILITY to something that requires the
declaration to be decorated.
I also marked `strong_equality::operator weak_equality()` as
`_LIBCPP_INLINE_VISIBILITY`, since it seems like it had been forgotten.
This came up while trying to get rid of `__attribute__((__always_inline__))`
in favor of `__attribute__((internal_linkage))`.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D49104
llvm-svn: 336665
* Remove unused type from is_assignable.pass.cpp
* Don't specialize `common_type<::X<float>>` in common_type.pass.cpp, which violates the requirements of [meta.trans.other]/5
llvm-svn: 336618
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.
2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.
llvm-svn: 336382
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Reviewers: EricWF
Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336369
Summary:
It is part of the synopsis in the Standard and <utility> does include it,
but it was left out of the synopsis comment.
Reviewers: EricWF, mclow.lists
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48611
llvm-svn: 336368
Summary: This is needed to implement `<charconv>`, otherwise `<charconv>` would need to include `<system_error>`, which pulls in `<string>` -- a header which the `<charconv>` proposal intends to keep away from.
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41347
llvm-svn: 336164
Summary:
_is_chartype_l (needed for isxdigit_l) in MinGW compares locale_t and NULL.
NULL is 'long long' for 64-bit, and this results in ambiguous overloads when
compiled with Clang. Define a concrete overload for the operators to fix the
ambiguity.
Reviewers: mstorsjo, EricWF, srhines, danalbert
Subscribers: christof, cfe-commits, ldionne
Differential Revision: https://reviews.llvm.org/D48749
llvm-svn: 336141
Summary:
Use _LIBCPP_MSVCRT_LIKE while configuring ELAST, so MinGW gets the same
configuration as MSVC.
Reviewers: compnerd, srhines, danalbert, mstorsjo
Subscribers: christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D48731
llvm-svn: 335916
r334477 renamed the cxx-headers target to cxx_headers, but various
pieces sort-of expect the target names to match the component (e.g.,
LLVM_DISTRIBUTION_COMPONENTS in the various bootstrap caches, which, via
some magic foreign to me, seems to expect cxx-headers,
install-cxx-headers, and install-cxx-headers-stripped to exist.)
Revert back to cxx-headers.
Differential Revision: https://reviews.llvm.org/D48701
llvm-svn: 335899
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
The paths output from llvm-config --cmakedir and from clang
--print-libgcc-file-name can contain backslashes, while CMake
can't handle the paths in this form.
This matches what compiler-rt already does (since SVN r203789
and r293195).
Differential Revision: https://reviews.llvm.org/D48356
llvm-svn: 335172
Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
llvm-svn: 334468
When built against the old libc++ version the test was causing linker error
Undefined symbols for architecture x86_64:
"std::experimental::fundamentals_v1::pmr::new_delete_resource()", referenced from:
void test_evil<WidgetV0, WidgetV0>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV1>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV2>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV0, WidgetV3>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV0>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV1>() in construct_piecewise_pair_evil.pass.cpp.o
void test_evil<WidgetV1, WidgetV2>() in construct_piecewise_pair_evil.pass.cpp.o
...
llvm-svn: 334431
Patch from Arthur O'Dwyer.
`__user_alloc_construct_impl` is used by <experimental/memory_resource>, but
this `__user_alloc_construct` is never used.
Also, `<experimental/memory_resource>` doesn't need a full definition of
`std::tuple`; just the forward declaration in `<__tuple>` will suffice.
Reviewed as https://reviews.llvm.org/D46806
llvm-svn: 334069
C++2a[container.requirements.general]p8 states that when move constructing
a container, the allocator is move constructed. Vector previously copy
constructed these allocators. This patch fixes that bug.
Additionally it cleans up some unnecessary allocator conversions
when copy constructing containers. Libc++ uses
__internal_allocator_traits::select_on_copy_construction to select
the correct allocator during copy construction, but it unnecessarily
converted the resulting allocator to the user specified allocator
type and back. After this patch list and forward_list no longer
do that.
Technically we're supposed to be using allocator_traits<allocator_type>::select_on_copy_construction,
but that should seemingly be addressed as a separate patch, if at all.
llvm-svn: 334053
These containers type-punned between pair<K, V> and pair<const K, V> as an
optimization. This commit instead provides access to the pair via a pair of
references that assign through to the underlying object. It's still undefined to
mutate a const object, but clang doesn't optimize on this for data members, so
this should be safe.
Differential revision: https://reviews.llvm.org/D47607
llvm-svn: 333948
Summary:
C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part).
This patch fixes the libc++ version of the __c11_atomic_load builtins defined for GCC's compatibility sake.
D47618 takes care of the clang side.
Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html
<rdar://problem/27426936>
Reviewers: EricWF, mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47613
llvm-svn: 333776
Summary:
The filesystem test was confused about access versus write / modification time. The spec says:
file_time_type last_write_time(const path& p, error_code& ec) noexcept;
Returns: The time of last data modification of p, determined as if by the value of the POSIX stat structure member st_mtime obtained as if by POSIX stat(). The signature with argument ec returns file_time_type::min() if an error occurs.
The test was looking at st_atime, not st_mtime, when comparing the result from last_write_time. That was probably due to using a pair instead of naming things nicely or using types. I opted to rename things so it's clearer.
This used to cause test bot failures.
<rdar://problem/40648859>
Reviewers: EricWF, mclow.lists, aemerson
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47557
llvm-svn: 333723
r333467 updated the symbols exported by libc++.so/dylib by changing
the ODR usage of __uncaught_exception/__uncaught_exceptions. This
should not be a breaking change.
llvm-svn: 333481
Patch from Arthur O'Dwyer.
In the TS, `uses_allocator` construction for `pair` tried to use an allocator
type of `memory_resource*`, which is incorrect because `memory_resource*` is
not an allocator type. LWG 2969 fixed it to use `polymorphic_allocator` as the
allocator type instead.
https://wg21.link/lwg2969
(D47090 included this in `<memory_resource>`; at Eric's request, I've split
this out into its own patch applied to the existing
`<experimental/memory_resource>` instead.)
Reviewed as https://reviews.llvm.org/D47109
llvm-svn: 333384
That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT"
r333327.
Marshall asked to revert:
Let's have a discussion about how to implement this so that it is more friendly
to people with installed code bases. We've had *extremely* loud responses to
unilaterally adding warnings - especially ones that can't be easily disabled -
to the libc++ code base in the past.
llvm-svn: 333351
r333325 from D47225 added warning checks, and the test was written to be C++11 correct by using ATOMIC_VAR_INIT (note that the committee fixed that recently...). It seems like GCC can't handle ATOMIC_VAR_INIT well because it generates 'type 'std::atomic<int>' cannot be initialized with an initializer list' on bot libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03. Drop the ATOMIC_VAR_INITs since they weren't required to test the diagnostics.
llvm-svn: 333327
Summary:
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that:
- A warning should be generated if the argument is null
- It is undefined behavior if the argument is null (because a dereference will segfault)
This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
The attributes are documented:
- https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
- https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes
I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters.
In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null.
<rdar://problem/18473124>
Reviewers: arphaman, EricWF
Subscribers: aheejin, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47225
llvm-svn: 333325
Some *_l functions were not available in some versions of Bionic. This CL
checks that the NDK version supports the functions, and if not, falls back
on the corresponding functions that don't take a locale.
Patch by Tom Anderson!
Differential Revision: https://reviews.llvm.org/D46558
llvm-svn: 332543
C11 defines `kill_dependency` as a macro in <stdatomic.h>. When you
include <atomic> after <stdatomic.h>, the macro clashes with
`std::kill_dependency` and causes multiple errors. Explicit error should
help in diagnosing those errors.
No change for working code that includes <atomic> before <stdatomic.h>.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists, jfb
Reviewed By: jfb
Subscribers: jfb, jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 332413
Checking for complete types is really rather tricky when you consider
the amount of specializations required to check a function type. This
specifically caused PR37407 where we incorrectly diagnosed
noexcept function types as incomplete (but there were plenty of other
cases that would cause this).
This patch removes the complete type checking for now. I'm going
to look into adding a clang builtin to correctly do this for us.
llvm-svn: 332040
Atomics in C and C++ are incompatible at the moment and mixing the
headers can result in confusing error messages.
Emit an error explicitly telling about the incompatibility. Introduce
the macro `__ALLOW_STDC_ATOMICS_IN_CXX__` that allows to choose in C++
between C atomics and C++ atomics.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 331379
When using an old version of glibc, a ::isinf(double) and ::isnan(double)
function is provided, rather than just the macro required by C and C++.
Displace this function using _LIBCPP_PREFERRED_OVERLOAD where possible.
The only remaining case where we should get the wrong return type is now
glibc + libc++ + a non-clang compiler.
llvm-svn: 331241
seekoff.pass.cpp:
libc++'s tests are asserting things about the buffer passed to pubsetbuf. [filebuf.virtuals]/12 says that what the filebuf does with the buffer you give it is completely implementation defined. The MSVC++ implementation takes that buffer and hands it off to the CRT (by calling ::setvbuf) and the CRT doesn't necessarily follow the pattern this test wants.
This change simply makes asserts against the buffer's contents use LIBCPP_ASSERT instead of assert.
pbackfail.pass.cpp:
libc++'s tests are asserting about what characters will and will not be available in the putback area. [filebuf.virtuals]/9 says "The function can alter the number of putback positions available as a result of any call." This change LIBCPP_ASSERTS libc++'s behavior, but checks invariants of the putback area independently.
llvm-svn: 330999
Be defensive against a reentrant std::function::operator=(nullptr_t), in case
the held function object has a non-trivial destructor. Destroying the function
object in-place can lead to the destructor being called twice.
Patch by Duncan P. N. Exon Smith. C++03 support by Volodymyr Sapsai.
rdar://problem/32836603
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits, arphaman
Differential Revision: https://reviews.llvm.org/D34331
llvm-svn: 330885
These io_error asserts that std::errc::is_a_directory has message "Is a directory". On MSVC++ it reports "is a directory" (with a lowercase I). That doesn't matter for the ios_failure component being tested, so just implement in terms of system_category().message().
Reviewed as https://reviews.llvm.org/D45715
llvm-svn: 330791
There are 3 changes:
* Renamed genertor.pass.cpp to generator.pass.cpp
* Removed nothing_to_do.pass.cpp
* Mark GCC 4.9 as UNSUPPORTED for the test files that have negative
narrowing conversion SFINAE test (see GCC PR63723).
llvm-svn: 330655
Summary:
The patch includes all declarations, and also implements the following features:
* ABI.
* narrowing-conversion related SFIANE, including simd<> ctors and (static_)simd_cast.
Reviewers: mclow.lists, EricWF
Subscribers: lichray, sanjoy, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D41148
llvm-svn: 330627
Summary:
It is immediately preceded by this check:
#if _MSC_VER < 1900
#error "MSVC versions prior to Visual Studio 2015 are not supported"
#endif
Reviewers: EricWF
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D45829
llvm-svn: 330360
The strto* family was introduced in android O (API Level 26). However,
the support headers were adjusted to indicate that all locale aware
functions were added in L. Provide stubs for the locale aware strto*
family until O.
llvm-svn: 330045
This test code triggers the MSVC warning:
"unary minus operator applied to unsigned type, result still unsigned"
Although it would be possible to change the test code to avoid
this warning, I have chosen to simply silence it.
Fixes D45594.
llvm-svn: 329976
Replace unary_function inheritance (which was never required,
even in C++98) with argument_type and result_type typedefs.
This increases portability, as unary_function was removed in C++17
and MSVC has implemented that removal.
Fixes D45596.
llvm-svn: 329974
MSVC emits "warning C4244: 'initializing': conversion from 'int'
to 'short', possible loss of data" when it sees pair<Whatever, short>
constructed from (whatever, 4), because int is being truncated to
short within pair's constructor. (The compiler doesn't take into
account the fact that 4 is a literal at the callsite; it generates
this warning when the constructor is instantiated, because it might
be called with a runtime-valued int that would actually truncate.)
Instead of static_cast<short>, we can simply change short to int
in these tests, without affecting the pair operations that they're
trying to test: move assignment, convert copy construction, and
convert move construction.
Fixes D45016.
llvm-svn: 329973
This avoids the need for a custom generated config file which is desired
because the custom config files differs per-target which means we cannot
reuse headers across different targets.
Differential Revision: https://reviews.llvm.org/D45304
llvm-svn: 329770
Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
llvm-svn: 329544
Patch from Joe Loser.
Several unit tests meaning to test the behavior of lvalue insertion incorrectly
pass rvalues. Fixes bug PR # 27394
Reviewed as https://reviews.llvm.org/D44411
llvm-svn: 329541
Summary:
D44883 extends -Wself-assign to also work on C++ classes.
These new warnings pop up in the test suite, so they have to be silenced.
Please refer to the D45082 for disscussion on whether this is the right way to solve this.
Testing: `ninja check-libcxx check-libcxxabi` in stage-2 build.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: Quuxplusone, cfe-commits
Differential Revision: https://reviews.llvm.org/D45128
llvm-svn: 329490
this patch adds the <compare> header and implements all of it
except for [comp.alg].
As I understand it, the header is needed by the compiler in
when implementing the semantics of operator<=>. For that reason
I feel it's important to land this header early, despite
all compilers lacking support.
llvm-svn: 329460
When libcxx is built in tree for a host which requires libatomic, LLVM's
configuration steps will determine it is required and add it to
CMAKE_REQUIRED_LIBRARIES. When libcxx is later configured, it tests if it
has C++ atomics without libatomic. The test erroneously passes as libatomic
is already part of the set of required libraries.
In turn, a number of the atomic tests will fail as they require libatomic
but the test suite is configured not to use libatomic.
Address this by always dropping libatomic from the set of required libraries
before determining if LIBCXX_HAVE_CXX_ATOMICS_WITHOUT_LIB is true,
then restoring the set of required libraries.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D43509
llvm-svn: 329167
This patch does some housekeeping for the new <version> header.
It adds it to the module.modulemap, and the double_include.sh.cpp test.
Additionally it corrects the // UNSUPPORTED options for the libc++
specific test. The header needs to compile under C++03 to support
modules, and it should compile under all available compilers.
llvm-svn: 329144
GLIBC 2.27 changed the locale data for fr_FR and ru_RU. In particular
they change the decimal and thousands separators used. This patch
makes the locale tests tolerate the updated locales.
llvm-svn: 329143
This patch implements P0430R2, who's largest change is adding the path::format
enumeration for supporting path format conversions in path constructors.
However, since libc++'s filesystem only really supports POSIX like systems,
there are no real changes needed. This patch simply adds the format enum
and then ignores it when it's passed to constructors.
llvm-svn: 329031
This is a fairly large patch that implements all of the filesystem NB comments
and the relative paths changes (ex. adding weakly_canonical). These issues
and papers are all interrelated so their implementation couldn't be split up
nicely.
This patch upgrades <experimental/filesystem> to match the C++17 spec and not
the published experimental TS spec. Some of the changes in this patch are both
API and ABI breaking, however libc++ makes no guarantee about stability for
experimental implementations.
The major changes in this patch are:
* Implement NB comments for filesystem (P0492R2), including:
* Implement `perm_options` enum as part of NB comments, and update the
`permissions` function to match.
* Implement changes to `remove_filename` and `replace_filename`
* Implement changes to `path::stem()` and `path::extension()` which support
splitting examples like `.profile`.
* Change path iteration to return an empty path instead of '.' for trailing
separators.
* Change `operator/=` to handle absolute paths on the RHS.
* Change `absolute` to no longer accept a current path argument.
* Implement relative paths according to NB comments (P0219r1)
* Combine `path.cpp` and `operations.cpp` since some path functions require
access to the operations internals, and some fs operations require access
to the path parser.
llvm-svn: 329028
Libc++ implements the pair& operator=(pair<U, V>) assignment operator
using a single template that handles assignment from all tuple-like types.
This patch moves the test for that to the libcxx test directory since
it's non-standard. It also adds additional tests to the std/.../pair
directory to test the standard behavior this template implements.
llvm-svn: 328758
This patch corrects num_get for unsigned types to support strings
with a leading `-` character. According to the standard the
number should be parsed as an unsigned integer and then
negated.
llvm-svn: 328751
The NB comments for filesystem changed permissions and added
a new enum `perm_options` which control how the permissions
are applied.
This implements than NB resolution
llvm-svn: 328476
As I move towards implementing std::filesystem, there is a need to
make the existing tests run against both the std and experimental versions.
Additionally, it's helpful to allow running the tests against other
implementations of filesystem.
This patch converts the test to easily target either. First, it
adds a filesystem_include.hpp header which is soley responsible
for selecting and including the correct implementation. Second,
it converts existing tests to use this header instead of including
filesystem directly.
llvm-svn: 328475
This partially reverts commit r328261. The GCC bug has been fixed in
trunk and has never existed in a released version. Therefore the changes
to variant are unneeded.
However, the additional tests have been left in place.
llvm-svn: 328388
Some debian libc++ bots started having failures in the locale
tests due to what I assume is a change in the locale data for fr_FR
in glibc.
This change prints the actual value from the test to help debugging.
It should be reverted once the bots cycle.
llvm-svn: 328268
This fixes a couple of tests which produced a warning that a 'throw'
occurred in a noexcept function (by way of _LIBCPP_ASSERT). It does
so by hiding the 'throw' across an opaque function boundary.
This fix isn't ideal, since we still have _LIBCPP_ASSERT's in functions
marked noexcept -- and this problem should be addressed in the future.
However, throwing _LIBCPP_ASSERT is really only meant to allow testing
of the assertions, and is not yet ready for general use.
llvm-svn: 328265
This patch works around variant test failures which are new to
GCC 8. GCC 8 either doesn't perform SFINAE in lexical order, or
it doesn't halt after encountering the first failure. This
causes hard error to occur instead of substitution failure.
See gcc.gnu.org/PR78489
llvm-svn: 328261
The new/delete tests, in particular those which test replacement
functions, often fail when the optimizer is enabled because the
calls to new/delete may be optimized away, regardless of their side-effects.
This patch converts the tests to use DoNotOptimize in order to prevent
the elision.
llvm-svn: 328245
This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-aligned
types.
__libcpp_allocate/deallocate now take an alignment parameter, and when
the specified alignment is greater than that supported by malloc/new,
the aligned version of operator new is called (assuming it's available).
When aligned new isn't available, the old behavior has been kept, and the
alignment parameter is ignored.
This patch depends on recent changes to __builtin_operator_new/delete which
allow them to be used to call any regular new/delete operator. By using
__builtin_operator_new/delete when possible, the new/delete erasure optimization
is maintained.
llvm-svn: 328180
After two failed attempts last week to make this work I am
going back to a known good method of making this test pass on
macOS...adding the current apple-clang version to the
UNSUPPORTED list.
During a previous patch review (https://reviews.llvm.org/D44103)
it was suggested to just XFAIL libcpp-no-deduction-guides
as was done to iter_alloc_deduction.pass.cpp. However
this caused a an unexpected pass on:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std/builds/214
I then attempted to just mark libcpp-no-deduction-guides
as UNSUPPORTED, however this caused an additional bot
failure. So I reverted everything (https://reviews.llvm.org/rCXX327191).
To solve this and get work unblocked I am adding
apple-clang-9 to the original UNSUPPORTED list.
llvm-svn: 327304
When the generated __config file is being used, it is currently only
copied during installation process. However, that means that the file
that gets copied into LLVM build directory is the vanilla __config file,
and any parts of the build that depend on the just built toolchain like
sanitizers will get that instead of the generated version. To avoid this
issue, we need to copy the generated header into the LLVM build
directory as well.
Differential Revision: https://reviews.llvm.org/D43797
llvm-svn: 327194
Summary: Refactor the previous version method of marking each apple-clang version as UNSUPPORTED and just XFAIL'ing the libcpp-no-deduction-guides instead. This brings this test inline with the same style as iter_alloc_deduction.pass.cpp
Reviewers: EricWF, dexonsmith
Reviewed By: EricWF
Subscribers: EricWF, vsapsai, vsk, cfe-commits
Differential Revision: https://reviews.llvm.org/D44103
llvm-svn: 327178
shrink_to_fit() ends up doing a lot work to get information that we
already know since we just called clear(). This change seems concise
enough to be worth the couple extra lines and my benchmarks show that it
is indeed a pretty decent win. It looks like the same thing is going on
twice in __copy_assign_alloc(), but I didn't want to go overboard since
this is my first contribution to llvm/libc++.
Patch by Timothy VanSlyke!
Differential Revision: https://reviews.llvm.org/D41976
llvm-svn: 327064
APFS minimum supported file write time is -2^63 nanoseconds, which doesn't go
as far as `file_time_type::min()` that is equal to -2^63 microseconds on macOS.
This change doesn't affect filesystems that support `file_time_type` range only
for in-memory file time representation but not for on-disk representation. Such
filesystems are considered as `SupportsMinTime`.
rdar://problem/35865151
Reviewers: EricWF, Hahnfeld
Subscribers: jkorous-apple, mclow.lists, cfe-commits, christof
Differential Revision: https://reviews.llvm.org/D42755
llvm-svn: 326383
test/std/numerics/numeric.ops/exclusive.scan/exclusive_scan.pass.cpp
test/std/numerics/numeric.ops/exclusive.scan/exclusive_scan_init_op.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan_op.pass.cpp
test/std/numerics/numeric.ops/inclusive.scan/inclusive_scan_op_init.pass.cpp
test/std/numerics/numeric.ops/transform.exclusive.scan/transform_exclusive_scan_init_bop_uop.pass.cpp
test/std/numerics/numeric.ops/transform.inclusive.scan/transform_inclusive_scan_bop_uop.pass.cpp
test/std/numerics/numeric.ops/transform.inclusive.scan/transform_inclusive_scan_bop_uop_init.pass.cpp
Fix MSVC x64 truncation warnings.
warning C4267: conversion from 'size_t' to 'int', possible loss of data
test/std/strings/basic.string/string.modifiers/string_append/push_back.pass.cpp
Fix MSVC uninitialized memory warning.
warning C6001: Using uninitialized memory 'vl'.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/PR20855_tuple_ref_binding_diagnostics.pass.cpp
Include <cassert> for the assert() macro.
Fixes D43273.
llvm-svn: 326120
This commit indents each level by two space characters, e.g.
#if defined(CONDITION)
# define _LIBCPP_NAME VALUE
#else
# define _LIBCPP_NAME VALUE
#endif
The simple #ifndef, #define, and #endif sequences are not indented, e.g.
#ifndef _LIBCPP_NAME
#define _LIBCPP_NAME ...
#endif
llvm-svn: 326027
Summary:
These flags can be specified using the CMake variables
LIBCXX_TEST_LINKER_FLAGS and LIBCXX_TEST_COMPILER_FLAGS.
When building the tests for CHERI I need to pass additional
flags (such as -mabi=n64 or -mabi=purecap) to the compiler
for our test configurations
Reviewers: EricWF
Reviewed By: EricWF
Subscribers: christof, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D42139
llvm-svn: 325914
Summary:
Certain C libraries require configuration macros defined in __config
to provide the correct functionality for libc++. This patch ensures
that the C header math.h is always included after the __config
header. It also adds a Windows-specific #if guard for the case when
the C math.h file is included the second time, as suggested by
Marshall in https://reviews.llvm.org/rL323490.
Fixes PR36382.
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: cfe-commits, pcc, christof, rogfer01
Differential Revision: https://reviews.llvm.org/D43579
llvm-svn: 325760
Summary:
Currently std::asinh and std::acosh use std::pow to compute x^2. This
results in a significant error when computing e.g. asinh(i) or
acosh(-1).
This patch expresses x^2 directly via x.real() and x.imag(), like it
is done in libstdc++/glibc, and adds tests that checks the accuracy.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41629
llvm-svn: 325510
Summary:
Compiling `<functional>` in C++17 or higher mode results in:
```
functional:2500:1: warning: attribute '__visibility__' is ignored, place it after "class" to apply attribute to type declaration [-Wignored-attributes]
_LIBCPP_TYPE_VIS
^
__config:701:46: note: expanded from macro '_LIBCPP_TYPE_VIS'
# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
^
1 warning generated.
```
Fix it by putting the attribute after the `class` keyword.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43209
llvm-svn: 325027
Summary:
As noted in a discussion about testing the LLVM 6.0.0 release candidates
(with libc++) for FreeBSD, many tests turned out to fail with
"exception_ptr not yet implemented". This was because libc++ did not
choose the correct C++ ABI library, and therefore it fell back to the
`exception_fallback.ipp` header.
Since FreeBSD 10.x, we have been using libcxxrt as our C++ ABI library,
and its headers have always been installed in /usr/include/c++/v1,
together with the (system) libc++ headers. (Older versions of FreeBSD
used GNU libsupc++ by default, but these are now unsupported.)
Therefore, if we are building libc++ for FreeBSD, set:
* `LIBCXX_CXX_ABI_LIBNAME` to "libcxxrt"
* `LIBCXX_CXX_ABI_INCLUDE_PATHS` to "/usr/include/c++/v1"
by default.
Reviewers: emaste, EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: mgorny, cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D43166
llvm-svn: 324855
Patch from charlieio@outlook.com
Reviewed as https://reviews.llvm.org/D42354
When the following command is used:
> clang-cl -std:c++17 -Iinclude\c++\v1 hello.cc c++.lib
An error occurred:
In file included from hello.cc:1:
In file included from include\c++\v1\iostream:38:
In file included from include\c++\v1\ios:216:
In file included from include\c++\v1\__locale:15:
In file included from include\c++\v1\string:477:
In file included from include\c++\v1\string_view:176:
In file included from include\c++\v1\__string:56:
In file included from include\c++\v1\algorithm:643:
In file included from include\c++\v1\memory:656:
include\c++\v1\new(165,29): error: redefinition of 'align_val_t'
enum class _LIBCPP_ENUM_VIS align_val_t : size_t { };
^
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\vcruntime_new.h(43,16): note:
previous definition is here
enum class align_val_t : size_t {};
^
1 error generated.
vcruntime_new.h has defined align_val_t, libcxx need hide align_val_t.
This patch fixes that error.
llvm-svn: 324853
Patch from ngolovliov@gmail.com
Reviewed as: https://reviews.llvm.org/D42344
As described in llvm.org/PR30959, the current
implementation of std::{map, key}::{count, equal_range} in libcxx is
non-conforming. Quoting the C++14 standard [associative.reqmts]p3
> The phrase “equivalence of keys” means the equivalence relation imposed by
> the comparison and not the operator== on keys. That is, two keys k1 and k2 are
> considered to be equivalent if for the comparison object comp,
> comp(k1, k2) == false && comp(k2, k1) == false.
In the same section, the requirements table states the following:
> a.equal_range(k) equivalent to make_pair(a.lower_bound(k), a.upper_bound(k))
> a.count(k) returns the number of elements with key equivalent to k
The behaviour of libstdc++ seems to conform to the standard here.
llvm-svn: 324799
Summary:
Currently libc++ implements some operations on valarray by using the
resize method. This method has a parameter with a default value.
Because of this, valarray may spuriously construct and destruct
objects of valarray's element type.
This patch fixes this issue and adds corresponding test cases.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D41992
llvm-svn: 324596
An array T[1] isn't necessarily the same say when it's
a member of a struct. This patch addresses that problem and corrects
the tests to deal with it.
llvm-svn: 324545
Summary:
This patch fixes llvm.org/PR35491 and LWG2157 (https://cplusplus.github.io/LWG/issue2157)
The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: lichray, cfe-commits
Differential Revision: https://reviews.llvm.org/D41223
llvm-svn: 324526
The 10.13 SDK always defines utimensat() (with an availability(macosx=10.13) annotation)
and unconditionally defines UTIME_OMIT, so use the compile-time availability macros
on Apple platforms instead.
For people statically linking libc++, it might make sense to also provide an opt-in
option for using __builtin_available() to dynamically check for the OS version,
but for now let's do the smallest thing needed to unbreak the build.
Based on a patch by Eric Fiselier <eric@efcs.ca>: https://reviews.llvm.org/D34249
Fixes PR33469.
llvm-svn: 324385
Revert "Fix initialization of array<const T, 0> with GCC."
Revert "Make array<const T, 0> non-CopyAssignable and make swap and fill ill-formed."
This reverts commit r324182, r324185, and r324194 which were causing issues with zero-length std::arrays.
llvm-svn: 324309
Previously, when handling zero-sized array of const objects we
used a const version of aligned_storage_t, which is not an array type.
However, GCC complains about initialization of the form: array<const T, 0> arr = {};
This patch fixes that bug by making the dummy object used to represent
the zero-sized array an array itself. This avoids GCC's complaints
about the uninitialized const member.
llvm-svn: 324194
This patch removes the noexcept declaration from filesystem
operations which require creating temporary paths or
creating a directory iterator. Either of these operations
can throw.
llvm-svn: 324192
Because path can be constructed from a ton of different types, including string
and wide strings, this caused it's streaming operators to suck up all sorts
of silly types via silly conversions. For example:
using namespace std::experimental::filesystem::v1;
std::wstring w(L"wide");
std::cout << w; // converts to path.
This patch tentatively adopts the resolution to LWG2989 and fixes the issue
by making the streaming operators friends of path.
llvm-svn: 324189
The standard isn't exactly clear how std::array should handle zero-sized arrays
with const element types. In particular W.R.T. copy assignment, swap, and fill.
This patch takes the position that those operations should be ill-formed,
and makes changes to libc++ to make it so.
This follows up on commit r324182.
llvm-svn: 324185
Summary:
This patch fixes llvm.org/PR35491 and LWG2157 (https://cplusplus.github.io/LWG/issue2157)
The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: lichray, cfe-commits
Differential Revision: https://reviews.llvm.org/D41223
llvm-svn: 324182
When Clang encounters an already invalid class declaration, it can
emit incorrect diagnostics about the exception specification on
some of its members. This patch temporarily works around that
incorrect diagnostic.
The clang bug was introduced in r324062.
llvm-svn: 324164
Clang previously reported an empty union as having a unique object
representation. This was incorrect and was fixed in a recent Clang commit.
This patch fixes the libc++ tests.
llvm-svn: 324153
According to [1], forms 2 and 4 of std::is_permutation should use the passed in
binary predicate to compare elements. operator== should only be used for forms
1 and 3 which do not take a binary predicate.
This CL fixes forms 2 and 4 which relied on operator== for some comparisons.
[1] http://en.cppreference.com/w/cpp/algorithm/is_permutation
Patch by Thomas Anderson!
Differential Revision: https://reviews.llvm.org/D42518
llvm-svn: 323563
Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.
Differential Revision: https://reviews.llvm.org/D42459
llvm-svn: 323492
We need to use the vcruntime declarations on Windows to avoid an
ODR violation involving rtti.obj, which provides the definition of
the runtime function implementing dynamic_cast and depends on the
vcruntime implementations of bad_cast and bad_typeid.
Differential Revision: https://reviews.llvm.org/D42220
llvm-svn: 323491
Code on Windows expects to be able to do:
#define _USE_MATH_DEFINES
#include <math.h>
and receive the definitions of mathematical constants, even if <math.h>
has previously been included. To support this scenario, re-include
<math.h> every time the wrapper header is included.
Differential Revision: https://reviews.llvm.org/D42403
llvm-svn: 323490
Shoaib Meenai pointed out this will break standalone builds when built without llvm.
Differential Revision: https://reviews.llvm.org/D42459
llvm-svn: 323459
Clang and llvm already use llvm_setup_rpath(), so this change will
help standarize rpath usage across all projects.
Differential Revision: https://reviews.llvm.org/D42459
llvm-svn: 323453
There was a bug in the implementation of splice where the container
sizes were updated before decrementing one of the iterators. Afterwards,
the result of decrementing the iterator was flagged as UB by the debug
implementation because the container was reported to be empty.
This patch fixes that bug by delaying the updating of the container
sizes until after the iterators have been correctly constructed.
llvm-svn: 323390
Summary:
See https://bugs.llvm.org/show_bug.cgi?id=20855
Libc++ goes out of it's way to diagnose `std::tuple` constructions which are UB due to lifetime bugs caused by reference creation. For example:
```
// The 'const std::string&' is created *inside* the tuple constructor, and its lifetime is over before the end of the constructor call.
std::tuple<int, const std::string&> t(std::make_tuple(42, "abc"));
```
However, we are over-aggressive and we incorrectly diagnose cases such as:
```
void foo(std::tuple<int const&, int const&> const&);
foo(std::make_tuple(42, 42));
```
This patch fixes the incorrectly diagnosed cases, as well as converting the diagnostic to use the newly added Clang trait `__reference_binds_to_temporary`. The new trait allows us to diagnose cases we previously couldn't such as:
```
std::tuple<int, const std::string&> t(42, "abc");
```
Reviewers: rsmith, mclow.lists
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41977
llvm-svn: 323380
Summary:
Currently when a regular expression contains an invalid character
class name std::regex constructors throw an std::regex_error with
std::regex_constants::error_brack code.
This patch changes the code to std::regex_constants::error_ctype and
adds a test.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42291
llvm-svn: 323322
Some users may have a custom build system which gives a different
name to the libc++ archive (or does not create an archive at all,
instead passing the object files directly to the linker). Give those
users a way to disable auto-linking.
Differential Revision: https://reviews.llvm.org/D42436
llvm-svn: 323300
The language standard does not define a function with this name,
so it is part of the user's namespace. This change fixes a duplicate
symbol error that occurs when a user attempts to define a function
with this name.
Differential Revision: https://reviews.llvm.org/D42405
llvm-svn: 323237
This is an MSVC standard library extension. It seems like a reasonable
enough extension to me because wchar_t* is the native format for
filenames on that platform.
Differential Revision: https://reviews.llvm.org/D42225
llvm-svn: 323170
This allows us to avoid polluting the namespace of users of <thread>
with the definitions in windows.h.
Differential Revision: https://reviews.llvm.org/D42214
llvm-svn: 323169
When CMAKE_SYSROOT or CMAKE_FIND_ROOT_PATH is set, cmake
recommends setting CMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY
globally which means find_path() always prepends CMAKE_SYSROOT or
CMAKE_FIND_ROOT_PATH to all paths used in the search.
However, this find_path() invocation is looking for a path in the
libcxxabi project on the host system, not the target system,
which can be done by passing NO_CMAKE_FIND_ROOT_PATH.
Differential Revision: https://reviews.llvm.org/D41622
llvm-svn: 323143
This patch fixes almost all currently failing tests when
using GCC ToT.
The specific changes are:
(A) Workaround gcc.gnu.org/PR83921 which rejects variables w/o initializers
in constexpr contexts -- even when the variable is an empty class. This
bug has been worked around at all callsites by adding an initializer.
Additionally a new test, constexpr_init.pass.cpp, has been added to
test that Clang doesn't suffer from these bugs.
(B) Fix streambuf.assign/swap.pass.cpp. This test was never actually
calling the swap method as intended. In fact, the swap function it
intended to call was ill-formed when instantiated. GCC diagnosed
this ill-formedness w/o needing an instantiation.
(C) size_delete11.pass.cpp was fixed by adding c++2a to the list of
unsupported dialects.
llvm-svn: 322810
It turns out that the MSVC headers define these functions without
dllimport even when compiling with /MD. This change fixes the resulting
compile-time error.
Differential Revision: https://reviews.llvm.org/D42207
llvm-svn: 322794
Previously .fail.cpp tests for nodiscard were run with -Wunused-result
being a warning, not an error, when the compiler didn't support -verify.
When -verify isn't enabled this change judiciously adds -Werror=unused-result
when to only the failure tests containing the // expected-error string for nodiscard.
As a drive-by change, this patch also adds a missing // UNSUPPORTED: c++2a to
a test which was only supposed to run in C++ <= 11.
llvm-svn: 322776
The specification of this function mandates a cast to uninitialized
T*, which is forbidden under CFI.
Differential Revision: https://reviews.llvm.org/D42146
llvm-svn: 322744
Inline the provided "fallback" definitions (which seem to always be
taken) that expand to __cdecl into users. The fallback definitions
for the *CRTIMP* macros were wrong in the case where the CRT is being
linked statically, so define our own macro as a replacement.
Differential Revision: https://reviews.llvm.org/D42158
llvm-svn: 322617
type 'result_type' to 'double'. The only thing that we ever do with
these numbers is to promote them to 'double' and use them in a division.
For small result_types, the values were getting truncated, skewing the
results. Thanks to James Nagurne for the suggestion.
llvm-svn: 322556
It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p9:
[...] In any case, if n is greater than zero it then stores a null
character into the next successive location of the array.
rdar://problem/35566567
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40677
llvm-svn: 322326
An application may determine whether the C standard library is glibc
by testing whether __GLIBC_PREREQ is defined. This breaks if libc++
provides its own definition. Instead, define our own macro in our
namespace with the desired semantics.
Differential Revision: https://reviews.llvm.org/D41892
llvm-svn: 322201
test/support/msvc_stdlib_force_include.hpp
When testing MSVC's STL with C1XX, simulate a couple more compiler feature-test macros.
When testing MSVC's STL, simulate a few library feature-test macros.
test/std/atomics/atomics.lockfree/isalwayslockfree.pass.cpp
The vector_size attribute is a non-Standard extension that's supported by Clang and GCC,
but not C1XX. Therefore, guard this with `__has_attribute(vector_size)`.
Additionally, while these tests pass when MSVC's STL is compiled with Clang,
I don't consider this to be a supported scenario for our library,
so also guard this with defined(_LIBCPP_VERSION).
test/std/utilities/function.objects/func.not_fn/not_fn.pass.cpp
N4713 23.14.10 [func.not_fn]/1 depicts only `call_wrapper(call_wrapper&&) = default;`
and `call_wrapper(const call_wrapper&) = default;`. According to
15.8.2 [class.copy.assign]/2 and /4, this makes call_wrapper non-assignable.
Therefore, guard the assignability tests as libc++ specific.
Add a (void) cast to tolerate not_fn() being marked as nodiscard.
Fixes D41213.
llvm-svn: 322144
Seems to have broken some tests since I first wrote this a while
back. Will reland after checking what went wrong with the tests.
This reverts commit 7023194c8d11a081fd01ed25308b3d60193c6a06.
llvm-svn: 322039
Summary:
After rL319736 for D28253 (which fixes PR28929), gcc cannot compile `<memory>` anymore in pre-C+11 modes, complaining:
```
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::make_shared(_A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4365:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4365:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::allocate_shared(const _Alloc&, _A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4444:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4444:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
```
This is also reported in https://bugs.freebsd.org/224946 (FreeBSD is apparently one of the very few projects that regularly builds programs against libc++ with gcc).
The reason is that the static assertions are invoking `is_constructible` with three arguments, while gcc does not have the built-in `is_constructible` feature, and the pre-C++11 `is_constructible` wrappers in `<type_traits>` only provide up to two arguments.
I have added additional wrappers for three arguments, modified the `is_constructible` entry point to take three arguments instead, and added a simple test to is_constructible.pass.cpp.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: krytarowski, cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D41805
llvm-svn: 321963
Reviewed as https://reviews.llvm.org/D41748
* These tests use function objects from functional, back_inserter from iterator, and equal from algorithm, so add those headers.
* The use of iota targeting vector<unsigned char> with an int parameter triggers warnings on MSVC++ assigning an into a unsigned char&; so change the parameter to unsigned char with a static_cast.
* Avoid naming unary_function in identity here as that is removed in '17. (This also fixes naming _VSTD, _NOEXCEPT_, and other libcxx-isms)
* Change the predicate in the transform tests to add_ten so that problems with multiple application are caught.
llvm-svn: 321922
This allows keeping libcxx using win32 threads even if a
version of pthread.h is installed.
This matches the existing cmake option LIBCXX_HAS_PTHREAD_API.
Also add missing documentation about the internal define
_LIBCPP_HAS_THREAD_API_WIN32.
Differential Revision: https://reviews.llvm.org/D41764
llvm-svn: 321896
* _VSTD should be std.
* <utility> is needed for forward.
* unary_function is no longer standard (and unnecessary for this, a C++17-only test)
llvm-svn: 321847
Summary:
This warning is already suppressed on non-apple platforms, so
this change just suppresses it on apple as well.
Reviewers: EricWF, lichray
Reviewed By: lichray
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41248
llvm-svn: 321435
As a result of this change, the basic_stringbuf constructor that
takes a mode ends up leaving __hm_ set to 0, causing the comparison
"__hm_ - __str_.data() < __noff" in seekoff() to succeed, which caused
the function to incorrectly return -1. The fix is to account for the
possibility of __hm_ being 0 when computing the distance from __hm_
to the start of the string.
Differential Revision: https://reviews.llvm.org/D41319
llvm-svn: 321124
It turns out that this is the only change required in libcxx
for it to compile with the new `wasm32-unknown-unknown-wasm`
target recently added to Clang.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D41073
llvm-svn: 320925
Summary:
[libcxx] Fix basic_stringbuf constructor
The C++ Standard [stringbuf.cons]p1 defines the effects of the basic_stringbuf
constructor that takes ios_base::openmode as follows:
Effects: Constructs an object of class basic_stringbuf, initializing the
base class with basic_streambuf(), and initializing mode with which.
Postconditions: str() == "".
The default constructor of basic_streambuf shall initialize all its
pointer member objects to null pointers [streambuf.cons]p1.
Currently libc++ calls "str(string_type());" in the aforementioned constructor
setting basic_streambuf's pointers to a non-null value.
This patch removes the call (note that the postcondition str() == ""
remains valid because __str_ is default-initialized) and adds a test checking
that the basic_streambuf's pointers are null after construction.
Thanks Mikhail Maltsev for the patch.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40707
llvm-svn: 320604
benchmarks/util_smartptr.bench.cpp
Change CRLF to LF.
test/std/localization/locale.categories/category.monetary/locale.money.get/locale.money.get.members/get_long_double_fr_FR.pass.cpp
Consistently comment "\u20ac" as EURO SIGN, its Unicode name, instead of the actual Unicode character.
test/std/utilities/allocator.adaptor/allocator.adaptor.members/construct_type.pass.cpp
Avoid non-ASCII dash.
Fixes D40991.
llvm-svn: 320536
test/std/algorithms/alg.modifying.operations/alg.generate/generate_n.pass.cpp
Silence MSVC warning C4244. This is expected when passing
floating-point values for size.
test/std/utilities/template.bitset/bitset.members/to_ullong.pass.cpp
test/std/utilities/template.bitset/bitset.members/to_ulong.pass.cpp
Avoid MSVC "warning C4293: '<<': shift count negative or too big,
undefined behavior". MSVC sees (1ULL << N) and warns - being guarded
by const bool canFit is insufficient. A small change to the code
avoids the warning without the need for a pragma.
Remove a spurious printf() declaration from to_ullong.pass.cpp.
Change ULL to UL in to_ulong.pass.cpp. The ULL suffix was
probably copy-pasted.
test/std/utilities/tuple/tuple.general/ignore.pass.cpp
Use LIBCPP_STATIC_ASSERT for consistency with other files.
test/support/container_test_types.h
Fix a null pointer dereference, found by MSVC /analyze
warning C6011 "Dereferencing NULL pointer 'm_expected_args'."
Fixes D41030.
llvm-svn: 320535
Summary:
Introduce a new form of `result_of` without function type encoding.
Rename and split `is_callable/is_nothrow_callable` into `is_invocable/is_nothrow_invocable/is_invocable_r/is_nothrow_invocable_r` (and associated types accordingly)
Change function type encoding of previous `is_callable/is_nothrow_callable` traits to conventional template type parameter lists.
Reviewers: EricWF, mclow.lists, bebuch
Reviewed By: EricWF, bebuch
Subscribers: lichray, bebuch, cfe-commits
Differential Revision: https://reviews.llvm.org/D38831
llvm-svn: 320509
Currently libc++ defines operator== and operator!= as friend functions in the
definition of the istream_iterator class template. Such definition has a subtle
difference from an out-of-line definition required by the C++ Standard: these
functions can only be found by argument-dependent lookup, but not by qualified
lookup.
This patch changes the definition, so that it conforms to the C++ Standard and
adds a check involving qualified lookup to the test suite.
Patch contributed by Mikhail Maltsev.
Differential Revision: https://reviews.llvm.org/D40415
llvm-svn: 320363
These buildbots are using the deprecated target name install-libcxx-headers
instead of the more up to date install-cxx-headers, so I need to add an
install-libcxx-headers-stripped target to satisfy them.
llvm-svn: 320201
LLVM is gaining install-*-stripped targets to perform stripped installs,
and in order for this to be useful for install-distribution, all
potential distribution components should have stripped installation
targets. LLVM has a function to create these install targets, but since
we can't use LLVM CMake functions in libc++, let's do it manually.
Differential Revision: https://reviews.llvm.org/D40680
llvm-svn: 319959
The MSVC driver and clang do not link against the C++ runtime
explicitly. Instead, they rely on the auto-linking via the pragma
(through `use_ansi.h`) to link against the correct version of the C++
runtime. Attempt to do something similar here so that linking real C++
code on Windows does not require the user to explicitly specify
`c++.lib` when using libc++ as a C++ runtime on windows.
llvm-svn: 319816
The parameter was previously renamed but MSVC path was not updated.
Patch by Andrey Khalyavin.
Differential Revision: https://reviews.llvm.org/D40774
llvm-svn: 319802
Summary:
We want to automatically copy the appropriate mailing list
for review requests to the libc++ repository.
For context, see the proposal and discussion here:
http://lists.llvm.org/pipermail/cfe-dev/2017-November/056032.html
Similar to D40179, I set up a new Diffusion repository with callsign
"CXX" for libc++:
https://reviews.llvm.org/source/libcxx/
This explicitly updates libcxx's .arcconfig to point to the new
CXX repository in Diffusion, which will let us use Herald rule H268.
Reviewers: halyavin, EricWF, mclow.lists, compnerd, mstorsjo
Reviewed By: compnerd
Subscribers: cfe-commits, bkramer, dlj, sammccall, klimek, smeenai, mstorsjo, krytarowski
Differential Revision: https://reviews.llvm.org/D40500
llvm-svn: 319666
Use this source use on Fuchsia where this is the oficially way
to obtain randomness. This could be also used on other platforms
that already support getentropy such as *BSD or Linux.
Differential Revision: https://reviews.llvm.org/D40319
llvm-svn: 319523
AddLLVM is needed for several functions that are used in tests and
as such needs to be included from the right context which previously
wasn't the case.
Differential Revision: https://reviews.llvm.org/D40280
llvm-svn: 319515
Previously, the install command for the cxxabi headers specified
the wrong component, and therefore they were not being included
in the install-cxx command.
This patch corrects the component name.
llvm-svn: 318989
Fix the problem PR31516 with setting locale on Windows by wrapping
_locale_t with a pointer-like class.
Reduces 74 test failures in std/localization test suite to 47 test
failures (on llvm clang, Visual Studio 2015). Number of test failures
doesn't depend on the platform (x86 or x64).
Patch by Andrey Khalyavin.
Differential Revision: https://reviews.llvm.org/D40181
llvm-svn: 318902
r318862 added a fix for 0-termination input array in case of an error. Previous
libcxx versions don't have the fix and corresponding tests should be failing.
llvm-svn: 318863
It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p21:
In any case, if n is greater than zero, it then stores a null character
(using charT()) into the next successive location of the array.
Patch by Reimar Döffinger.
llvm-svn: 318862
In a17cd7c641c34b6c4bd4845a4d4fb590cb6c238c Marshall added assert(true) to the vector<bool>::size tests, which break on C1XX:
D:\Contest\gl0qojfu.5pe\src\qa\vc\libs\libcxx\upstream\test\std\containers\sequences\vector.bool\size.pass.cpp(62): error C2220: warning treated as error - no 'object' file generated
d:\contest\gl0qojfu.5pe\src\qa\vc\libs\libcxx\upstream\test\std\containers\sequences\vector.bool\size.pass.cpp(33) : warning C6326: Potential comparison of a constant with another constant.
d:\contest\gl0qojfu.5pe\src\qa\vc\libs\libcxx\upstream\test\std\containers\sequences\vector.bool\size.pass.cpp(52) : warning C6326: Potential comparison of a constant with another constant.
The corresponding test for vector::size asserts assert(c.size() == 3);, so I changed it to do that here.
llvm-svn: 318812
One can't replace vsscanf(_l) with a sscanf(_l) that doesn't
take a va_list.
This has been untouched since it was added in SVN r140728, so
apparently it hasn't been used since. One reason for this mistake
originally might have been that there was no _vsscanf_l until MSVC
2015.
Since it's unused, just remove this define.
Differential Revision: https://reviews.llvm.org/D40323
llvm-svn: 318810
The non-const data() member of std::string is only exposed
in C++17 and beyond. However std::string is externally instantiated
and so the member function needs to be exposed to be externally instantiated.
On Linux and OS X this shouldn't cause a problem, because
_LIBCPP_INLINE_VISIBILITY ensures the symbol is always inlined.
However on Windows, the symbol gets marked dllimport, but
there is no definition to import, causing link errors.
llvm-svn: 318690
Summary:
Currently `std::variant` always uses an unsigned int to store the variant index. However this isn't nessesary and causes `std::variant` to be larger than it needs to be in most cases.
This patch changes the index type to be `unsigned char` when possible, and `unsigned short` or `unsigned int` otherwise, depending on the size (Although it's questionable if it's even possible to create a variant with 65535 elements.
Unfortunately this change is an ABI break, and as such is only enabled in ABI v2.
Reviewers: mpark
Reviewed By: mpark
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40210
llvm-svn: 318621
Summary:
In the CHERI clang compiler __output and __input are keywords and therefore
we can't compile libc++ with our compiler.
Reviewers: mclow.lists, EricWF, theraven
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39537
llvm-svn: 318144
The commit r300140 changed the implementation of compressed_pair, but didn't add
_LIBCPP_INLINE_VISIBILITY to the constructors and get members of the
compressed_pair_elem class. This patch adds the visibility annotation.
I didn't find a way to test this change with libc++ regression tests.
rdar://35352579
Differential Revision: https://reviews.llvm.org/D39751
llvm-svn: 317816
r313500 added a fix for undefined "___cxa_deleted_virtual" symbol.
Previous libcxx versions don't have the fix and corresponding test
should be failing.
rdar://problem/34521053
Reviewers: EricWF, mclow.lists, ahatanak
Reviewed By: ahatanak
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D39776
llvm-svn: 317734
This patch teaches the test suite configuration about the -std=c++2a
flag. And, since it's the newest dialect, change the test suite to
choose it, if possible, by default.
llvm-svn: 317611
This patch changes the test suite to attempt and prefer -std=c++17 over
-std=c++1z. It also fixes the REQUIRES and UNSUPPORTED lit markers
to refer to c++17 over c++1z.
llvm-svn: 317610
Summary:
quick_exit() and at_quick_exit() were introduced in android NDK 21:
https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/stdlib.h#55
This CL conditions `_LIBCPP_HAS_QUICK_EXIT` on `__ANDROID_API__ >= 21`. The only place this macro is used is in some using declarations: `using ::quick_exit`, `using ::at_quick_exit`.
Also, add a missing include to sys/cdefs.h which is what defines `__BIONIC__`.
Reviewers: thakis, danalbert, EricWF
Reviewed By: danalbert
Subscribers: srhines, krytarowski
Differential Revision: https://reviews.llvm.org/D39479
llvm-svn: 317124
LWG 3013 points out that the constructors and increment members
of the directory iterators need to allocate, and therefore cannot
be marked noexcept.
It also points out that `is_empty` and `copy` likely need to allocate
as well, and as such can also not be noexcept.
This patch speculatively implements the resolution removing noexcept,
because libc++ does indeed have the possibility of throwing on allocation
failure.
llvm-svn: 316941
The guts of the increment method for recursive_directory_iterator
was failing to pass an error code object to calls to status/symlink_status,
which can throw under certain conditions.
This patch fixes the issues by correctly propagating the error codes.
However the noexcept still needs to be removed from the signature, as
mentioned in LWG 3014, but that change will be made in a separate commit.
llvm-svn: 316939
The logic to allocate a node within std::list was repeated
in a bunch of places. This is unneeded. This patch refactors
the shared logic into a single function to reduce duplication.
This patch is part of a set to clean up node construction in
general, but refactoring construction requires some more work
to make it work cleanly in C++03
llvm-svn: 316021
Previously this macro used 0/1 to indicate if it was set.
This is unlike all other libc++ configuration macros which
use ifdef/ifndef.
This patch makes this macro consistent with everything else.
llvm-svn: 315995
Summary:
The constructors `vector(Iter, Iter, Alloc = Alloc{})` and `assign(Iter, Iter)` don't correctly perform EmplaceConstruction from the result of dereferencing the iterator. This results in them performing an additional and unneeded copy.
This patch addresses the issue by correctly using `emplace_back` in C++11 and newer.
There are also some bugs in our `insert` implementation, but those will be handled separately.
@mclow.lists We should probably merge this into 5.1, agreed?
Reviewers: mclow.lists, dlj, EricWF
Reviewed By: mclow.lists, EricWF
Subscribers: cfe-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D38757
llvm-svn: 315994
The vcruntime headers are hairy and clash with both libc++ headers
themselves and other libraries. libc++ normally deals with the clashes
by deferring to the vcruntime headers and silencing its own definitions,
but for clients which don't want to depend on vcruntime headers, it's
desirable to support the opposite, i.e. have libc++ provide its own
definitions.
Certain operator new/delete replacement scenarios are not currently
supported in this mode, which requires some tests to be marked XFAIL.
The added documentation has more details.
Differential Revision: https://reviews.llvm.org/D38522
llvm-svn: 315234
Make it clear that these are intended only to force a specific ABI when
the autodetection would give the wrong result by renaming the cmake
options and adding separate forcing macros, as suggested by EricWF in
the post-commit review of r314949 and further discussed on IRC.
llvm-svn: 314965
libc++'s current heuristic for detecting Itanium vs. Microsoft ABI falls
short in some cases. For example, it will detect windows-itanium targets
as using the Microsoft ABI, since they set `_MSC_VER` (for compatibility
with Microsoft headers). Leave the current heuristic in place by default
but also allow users to explicitly specify the ABI if need be.
llvm-svn: 314949
Some ABI macros affect headers, so it's nice to have a site config
option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow
specifying a list of ABI macros to define in the site config.
The primary design constraint (as discussed with Eric on IRC a while
back) was to not have to repeat the ABI macro names in cmake, which only
leaves a free-form cmake list as an option. A somewhat unfortunate
consequence is that we can't verify that the ABI macros being defined
actually exist, though we can at least perform some basic sanity
checking, since all the ABI macros begin with _LIBCPP_ABI_.
Differential Revision: https://reviews.llvm.org/D36719
llvm-svn: 314946
Previously LIT would often fail while attempting to set up/configure
the test compiler; normally when attempting to dump the builtin macros.
This sort of failure provided no useful information about what went
wrong with the compiler, making the actual issues hard --- if not
impossible --- to debug easily.
This patch changes the LIT configuration to report the failure explicitly,
including the failed compile command and the stdout/stderr output.
llvm-svn: 314735
This warning "structure was padded due to alignment specifier" says
that the compiler is going to do exactly what you asked it to do.
It's triggered by the tests for over-aligned dynamic memory allocation.
llvm-svn: 314257
Despite a strong CMake warning that this is an unsupported
libcxx build configuration, some bots still rely on being
able to check out lit and libcxx independently with no
LLVM sources, and then run lit against libcxx.
A previous patch broke that workflow, so this is making it work
again. Unfortunately, it breaks generation of the llvm-lit
script for libcxx, but we will just have to live with that until
a solution is found that allows libcxx to make more use of
llvm build pieces. libcxx can still run tests by using the
ninja check target, or by running lit.py directly against the
build tree or source tree.
Differential Revision: https://reviews.llvm.org/D38057
llvm-svn: 313763
Summary:
This patch replaces __sync_* with __libcpp_atomic_* and adds a wrapper
function for __atomic_exchange to support _LIBCPP_HAS_NO_THREADS.
Reviewers: EricWF, jroelofs, mclow.lists, compnerd
Reviewed By: EricWF, compnerd
Subscribers: compnerd, efriedma, cfe-commits, joerg, llvm-commits
Differential Revision: https://reviews.llvm.org/D35235
llvm-svn: 313694
After speaking with the libcxx owners, they agreed that this is
a bug in the bot that needs to be fixed by the bot owners, and
the CMake changes are correct.
llvm-svn: 313643
This reverts commit 4ad71811d45268d81b60f27e3b8b2bcbc23bd7b9.
There is a bot that is checking out libcxx and lit with nothing
else and then running lit.py against the test tree. Since there's
no LLVM source tree, there's no LLVM CMake. CMake actually
reports this as a warning saying unsupported libcxx configuration,
but I guess someone is depending on it anyway.
llvm-svn: 313607
Patch from Eddie Elizondo. Reviewed as D37830 (https://reviews.llvm.org/D37830).
On MacOSX the following program:
struct S { virtual void f() = delete; };
int main() { new S; }
Fails with the following error:
Undefined symbols for architecture x86_64:
"___cxa_deleted_virtual"
This adds a fix to export the needed symbols.
Test:
> lit -sv test/libcxx/language.support/cxa_deleted_virtual.pass.cpp
> Testing Time: 0.21s
> Expected Passes : 1
llvm-svn: 313500
Clang recently changed the way it outputs static assert diagnostics.
This patch fixes libc++'s -verify tests so they tolerate both the old
and new message format.
llvm-svn: 313499
Microsoft's CRT already provides the const overloads, and it defines the
`_CRT_CONST_CORRECT_OVERLOADS` macro to indicate their presence. Check
for this macro before attempting to define our own const-correct
overloads, to avoid compiler warnings about casts dropping const
qualifiers.
llvm-svn: 313377
The RTTI structure is different on Windows when building under MS ABI.
Update the definition to reflect this. The structure itself contains an
area for caching the undecorated name (which is 0-initialized). The
decorated name has a bitfield followed by the linkage name. When
std::type_info::name is invoked for the first time, the runtime should
undecorate the name, cache it, and return the undecorated name. This
requires access to an implementation of __unDName. For now, return
the raw name.
This uses the fnv-1a hash to hash the name of the RTTI. We could use an
alternate hash (murmur? city?), but, this was the quickest to throw
together.
llvm-svn: 313344
There were a number of cases where __double_underscore functions,
for example __has_construct_test, were called without being qualified,
causing ADL to occur. This patch qualifies those calls to avoid this
problem.
Thanks to David L. Jones for point out the issue initially.
llvm-svn: 313324
If we define cmake macros that require a site config, and then undefine
all such macros, a stale site config header will be left behind.
Explicitly delete any generate site config if we don't need one to avoid
this.
Differential Revision: https://reviews.llvm.org/D36720
llvm-svn: 313284
Using the system default 'ar' might not be the right choice when
cross compiling.
Don't prepend the ar options by a dash, not all ar implementations
support that (llvm-ar doesn't).
Also pass the 's' option when creating the merged library, to create
an index.
Differential Revision: https://reviews.llvm.org/D37134
llvm-svn: 313122
This patch fixes llvm.org/PR34298. Previously libc++ incorrectly evaluated
the __invokable trait via the converting constructor `function(Tp)` [with Tp = std::function]
whenever the copy constructor or copy assignment operator
was required. This patch further constrains that constructor to short
circut before evaluating the troublesome SFINAE when `Tp` matches
std::function.
The original patch is from Alex Lorenz.
llvm-svn: 312892
This reverts commit r312890 because the test case fails to compile for
older versions of Clang that reject initializing a const object without
a user defined constructor.
Since this patch should go into 5.0.1, I want to keep it an atomic change,
and will re-commit it with a fixed test case.
llvm-svn: 312891
This patch fixes llvm.org/PR34298. Previously libc++ incorrectly evaluated
the __invokable trait via the converting constructor `function(Tp)` [with Tp = std::function]
whenever the copy constructor or copy assignment operator
was required. This patch further constrains that constructor to short
circut before evaluating the troublesome SFINAE when `Tp` matches
std::function.
The original patch is from Alex Lorenz.
llvm-svn: 312890
_strftime_l is only available in the numbered msvcrt versions
(starting from msvcr80.dll). In the default configuration, mingw
targets the unversioned msvcrt.dll - and there, _strftime_l is
not available (not even on windows 10).
If __MSVCRT_VERSION__ is set to a higher value (indicating a
non-default target and wanting to link to msvcrXX.dll), use the
correct function.
Differential Revision: https://reviews.llvm.org/D37468
llvm-svn: 312617
This is essential when building with -nodefaultlibs.
This is similar to what already is done in libcxxabi in SVN r302760.
Differential revision: https://reviews.llvm.org/D37207
llvm-svn: 312498
* Update specification text from N4387
* Delete not_brace_initializable.fail.cpp: it's redundant with nullopt_t.fail.cpp
* is_empty<T> implies is_class<T>
* is_literal is deprecated; directly verify that we can create a nullopt_t in a constexpr context
Differential Revision: D37024
llvm-svn: 312256
test/std/containers/Emplaceable.h
test/std/containers/NotConstructible.h
test/support/counting_predicates.hpp
Replace unary_function/binary_function inheritance with typedefs.
test/std/depr/depr.function.objects/depr.base/binary_function.pass.cpp
test/std/depr/depr.function.objects/depr.base/unary_function.pass.cpp
test/std/utilities/function.objects/func.require/binary_function.pass.cpp
test/std/utilities/function.objects/func.require/unary_function.pass.cpp
Mark these tests as requiring 98/03/11/14 because 17 removed unary_function/binary_function.
test/std/thread/futures/futures.task/futures.task.members/ctor_func_alloc.pass.cpp
test/std/thread/futures/futures.task/futures.task.nonmembers/uses_allocator.pass.cpp
Mark these tests as requiring 11/14 because 17 removed packaged_task allocator support.
test/std/utilities/function.objects/func.wrap/func.wrap.func/derive_from.pass.cpp
This test doesn't need to be skipped in C++17 mode. Only the construction of
std::function from an allocator needs to be skipped in C++17 mode.
test/std/utilities/function.objects/refwrap/refwrap.access/conversion.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.assign/copy_assign.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.const/copy_ctor.pass.cpp
test/std/utilities/function.objects/refwrap/refwrap.const/type_ctor.pass.cpp
When testing these reference_wrapper features, unary_function inheritance is totally irrelevant.
test/std/utilities/function.objects/refwrap/weak_result.pass.cpp
Define and use my_unary_function/my_binary_function to test the weak result type machinery
(which is still present in C++17, although deprecated).
test/support/msvc_stdlib_force_include.hpp
Now we can test C++17 strictly, without enabling removed features.
Fixes D36503.
llvm-svn: 311705
This improves readability and (theoretically) improves portability,
as _Ugly names are reserved.
This performs additional de-uglification, so all of these tests
follow the example of iterator.traits/empty.pass.cpp.
llvm-svn: 310761
libc++'s inline namespace can change depending on the ABI version.
Instead of hardcoding __1 in the manual Microsoft ABI manglings for the
iostream globals, stringify _LIBCPP_NAMESPACE and use that instead, to
work across all ABI versions.
llvm-svn: 310290
This function template is referenced inside class basic_string as a
friend function. The extern template declaration needs to be above that
friend declaration to actually take effect.
This is important because this function was marked as exported in
r307966, so without the extern template taking effect, it can leak into
other DSOs as a visible symbol.
llvm-svn: 309474
This makes them consistent (many comments already used uppercase).
The special REQUIRES, UNSUPPORTED, and XFAIL comments are excluded from this change.
llvm-svn: 309468
Creating a function pointer with proper parameters pointing to std::next() or std::prev() should work.
This change moves the invented paramater for enable_if over to the return type to resolve this QoI issue.
Patch by Jason Liu.
Differential Revision: https://reviews.llvm.org/D34649
llvm-svn: 308932
The set of #ifdefs used to handle the two incompatible variants of
strerror_r were not complete (they didn't handle newlib appropriately).
Rather than attempting to make the ifdefs more complex, make them
unnecessary by choosing which behavior to use dependent upon the
return type.
Reviewers: waltl
Differential Revision: https://reviews.llvm.org/D34294
llvm-svn: 308528
Some targets (e.g. Darwin) might have the Win32 API available, but they
do not use MSVC CRT. Assume _LIBCPP_MSVCRT only when _MSC_VER is available
and __MINGW32__ isn't defined.
Differential Revision: https://reviews.llvm.org/D34588
rdar://problem/32628786
llvm-svn: 308225
Once upon a time, extern templates used to be a Microsoft extension, so
cl would warn about their usage, and libc++ suppressed that warning.
They've long since been standardized, so the warning is defunct. (libc++
also doesn't currently support building with cl anyway.)
llvm-svn: 307997
It has an extern template instantiation declaration in the headers and a
corresponding instantiation definition in the library, so we must mark
it with _LIBCPP_FUNC_VIS to make it available outside the library.
This doesn't cause any ABI changes as-is since we don't build libc++
with hidden visibility (so the function is exported anyway). It's needed
for building libc++ with hidden visibility, however.
Clarify the Windows behavior for extern function templates while I'm
here, since this exercises that behavior.
llvm-svn: 307966
When using LIBCXX_ABI_UNSTABLE=YES, clang-cl gave the following warning:
P:\llvm_master\src\llvm\projects\libcxx\include\string(683,51):
warning: enumerator value is not representable in the underlying type
'int' [-Wmicrosoft-enum-value]
Fixed by switching from enums to static const size_type.
https://reviews.llvm.org/D35174
llvm-svn: 307751
The libc++ <__refstring> headers has no real reason why it should
be a public header that libc++ ships. The only reason it was in the include
directory was because libc++abi needed it to build the library.
However keeping <__refstring> a header had other problems, like requiring its
dependancies to also be in the headers. For that reason this patch
moves it into the source directory.
To work around libc++abi's need for this header a duplicated copy was added
to libc++abi in r307748. While duplicating the code is an unfortunate solution
it's the best solution that's currently possible.
In the future I would like to start a discussion on the mailing lists about
making libc++abi build as a sub-project of libc++, requiring the libc++ sources
always be present.
llvm-svn: 307749
This is going to be used by the runtime build in the multi-target
setup to allow using different install prefix for each target.
Differential Revision: https://reviews.llvm.org/D33762
llvm-svn: 307615
On Apple the test feature 'sanitizer-new-delete' was incorrectly
getting added to the LIT feature set, which mistakenly caused tests
to be disabled when using UBSAN (the feature is only needed with ASAN/MSAN/TSAN).
llvm-svn: 307518
32-bit powerpc provides a 64 bit time_t type and older ppc64 systems
provide time_t as a floating point type. This caused problems when building
operations.cpp since operations.cpp contained compile time tests for conversions
between time_t and filesystem time type.
When these tests failed they caused the libc++ build to fail as well. This is unfortunate.
This patch moves the tests out of the source file and into the test suite. It also
expands the tests to allow testing of the weird time_t configurations on all platforms.
llvm-svn: 307461
r283051 added some functions to cmath (in namespace std) that have the
same name as functions in math.h (in the global namespace). Clang's
limited support for `-fdelayed-template-parsing` chokes on this. Rename
the ones in `cmath` and their uses in `complex` and the test.
rdar://problem/32848355
llvm-svn: 307357
In order for IDE's like CLion to correctly parse and highlight the tests
it needs to know roughly how to build them. This patch adds a dummy CMake target
for each/all of the .pass.cpp tests in the test suite to solve this problem.
The target is only created when LIBCXX_CONFIGURE_IDE=ON, so it shouldn't affect
most users.
Originally I wasn't sure that this change deserved to live upstream, but it's
quite frustrating to edit libc++ tests using CLion or Visual Studio without it,
in particular the filesystem tests which rely heavily on macros. Even though the change
should have no effect on non-IDE users/configurations I decided to commit it upstream
with the hopes it will benefit somebody other than me.
llvm-svn: 307118
This patch speculatively implements the PR for LWG 2937, which fixes
two issues with equivalent.
(1) It makes equivalent("dne", "exists") an error. Previously only
equivalent("dne", "dne") was an error and the former case was not (it returned false).
Now equivalent reports an error when either input doesn't exist.
(2) It makes equivalent(p1, p2) well-formed when `is_other(p1) && is_other(p2)`.
Previously this was an error, but there is seemingly no reason why it should be on POSIX system.
llvm-svn: 307117
This reverts commit r306310.
r306310 causes clang to reject a call to an aligned allocation or
deallocation function if it is not implemented in the standard library
of the deployment target. This is not the desired behavior when users
have defined their own aligned functions.
rdar://problem/32664169
llvm-svn: 306859
Summary:
This reference to lit.util.capture is functionally identical to
subprocess.check_output, so this change switches to call the library routine
directly.
Reviewers: mzolotukhin, EricWF
Reviewed By: mzolotukhin
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D34841
llvm-svn: 306755
The string literal operators have implicit instantiations of
basic_string<char> and basic_string<wchar>, which prevent the dllimport
on the subsequent explicit instantiation declarations from having an
effect. Hoisting the explicit instantiations above the implicit ones
fixes the issue.
I think it's pretty unfortunate that the ordering has such an effect,
and I'd fixed the same issue for dllexport in r288682. dllimport is more
complicated from a codegen perspective, however, and clang's behavior of
ignoring the dllimport when there's a previous implicit instantiation is
consistent with cl, so changing the order is our only recourse.
llvm-svn: 306632
attribute.
This is needed because older versions of libc++ do not have these
operators. If users target an older deployment target and try to compile
programs in which these operators are explicitly called, the compiler
will complain.
The following is the list of minimum deployment targets for the four
OSes:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34556
llvm-svn: 306310
Clang and C1XX both complain about mismatched class/struct, but libc++ and MSVC's STL
differ on what they use for tuple_element/tuple_size, so there's no way to win here.
I'm reverting this part of my previous change. In the future, I'll have to suppress
the warning for one compiler or the other.
llvm-svn: 305854
Style/paranoia: 42.1 doesn't have an exact binary representation. Although this doesn't
cause failures, it makes me uncomfortable, so I'm changing it to 42.5.
C1XX rightly warns about unreferenced variables. Adding tests for their values
makes C1XX happy and improves test coverage.
C1XX (somewhat obnoxiously) warns about seeing a struct specialized as a class.
Although the Standard doesn't care, saying struct consistently is better.
(The Standard itself is still inconsistent about whether to depict tuple_element
and tuple_size as structs or classes.)
Fixes D33953.
llvm-svn: 305843
Remarks: This function shall not participate in overload resolution unless
`is_same_v<decay_t<T>, variant>` is false, unless `decay_t<T>` is
neither a specialization of `in_place_type_t` nor a specialization of
`in_place_index_t`, unless `is_constructible_v<Tj, T>` is true, and
unless the expression `FUN(std::forward<T>(t))` (with `FUN` being the
above-mentioned set of imaginary functions) is well formed.
Depends on D34111.
Reviewers: EricWF, K-ballo
Reviewed By: EricWF
Subscribers: fhahn
Differential Revision: https://reviews.llvm.org/D34112
llvm-svn: 305668
Most of filesystem/path.cpp uses string_view_t. This fixes the two spots
that use string_view directly.
https://reviews.llvm.org/D34332
llvm-svn: 305661
Fix an off-by-one in r302172, which triggered building local versions of
the iostreams when deploying to `<= macOS 10.9`, when it should have
been `< macOS 10.9`. 10.9 had the dylib support.
This defines `_LIBCPP_AVAILABILITY_NO_STREAMS_EXTERN_TEMPLATE` less
often, reducing code size for users with deployment targets of exactly
macOS 10.9 or iOS 7.0.
rdar://problem/32233981
llvm-svn: 305649
C99 at least. C89 still fails due to the use of block comments.
NOTE: Having libc++ on the include path when compiling C is not
recommended or ever really supported. However it happens often
enough that this change is warrented.
llvm-svn: 305539
It seems conceivable that a user would need to get a coroutine handle
having only a const reference to the promise_type, for example from
within a const member function of the promise.
This patch allows that use case. A coroutine_handle<const T> can be used
in essentially the same way a coroutine_handle<T>, ie to start and destroy
the coroutine. The constness of the promise doesn't/shouldn't propagate
to the handle.
llvm-svn: 305536
Previously the explicit instantiation for this was in locale.cpp,
but that didn't make much sense. This patch creates a new vector.cpp
source file to contain the explicit instantiation.
llvm-svn: 305442
The function num_get<_CharT>::stage2_int_prep makes unnecessary copy of src
into atoms when char_type is char. This can be avoided by creating
a switch on type and just returning __src when char_type is char.
Added the test case to demonstrate performance improvement.
In order to avoid ABI incompatibilities, the changes are guarded
with a macro _LIBCPP_ABI_OPTIMIZED_LOCALE_NUM_GET
Differential Revision: https://reviews.llvm.org/D30268
Reviewed by: EricWF
llvm-svn: 305427
Newlib 2.5 added the locale management functions, so it should not
include __nop_local_mgmt.h. This change adds proper guard around that
include statement.
For newlib 2.4, some releases contain these functions and some don't,
and they all have the same version numbers. This patch will work
properly with the initial "2.4.0" release which does not include these
functions and require __nop_local_mgmt.h.
This has been tested against newlib 2.2 and 2.5, and also sanity
checks against other different version numbers.
Patch by Martin J. O'Riordan and Walter Lee
Differential Revision: https://reviews.llvm.org/D32146
llvm-svn: 305394
locale.codecvt.byname/ctor_char.pass.cpp:
This test used to use "en_US" as a plain string instead of using platform_support.
Need to fix this because MS STL expects "en-US" instead.
platform_support.h:
These are the legacy Windows locale names. Should use IETF tags instead.
I've also added en_US, since a test was using that as a locale string as well.
msvc_stdlib_force_include.hpp:
Remove _MSVC_STL_VER. The libraries will directly define _MSVC_STL_VERSION in the future.
Fixes D29351.
llvm-svn: 305000
r304862 changed how CTD handles deducing a non-primary class template
using a non-dependent constructor of the primary template. This change
requires libc++ to provide explicit deduction guides to make scoped_lock
work again.
llvm-svn: 304955
On Bionic PTHREAD_MUTEX_INITIALIZER contains the expression "<enum-type> & <integer-type>",
which causes ADL to perform name lookup for operator&. During this lookup Clang decides
that it requires the default member initializer for std::mutex while defining the DMI
for std::mutex::__m_.
If I'm not mistaken this is caused by the explicit noexcept declaration on the defaulted
constructor.
This patch removes the explicit noexcept and instead allows the compiler to declare
the default constructor implicitly noexcept. It also adds a static_assert to ensure
that happens.
Unfortunatly because it's not easy to change the value of _LIBCPP_MUTEX_INITIALIZER
for a single test there is no good way to test this patch.
The Clang behavior causing the trouble here was introduced in r287713, which first
appears in the 4.0 release.
llvm-svn: 304942
Summary:
- Removed the move-constructibe requirement from copy-assignable.
- Updated `__assign_alt` such that we direct initialize if
`_Tp` can be `nothrow`-constructible from `_Arg`, or `_Tp`'s
move construction can throw. Otherwise, construct a temporary and move it.
- Updated the tests to remove the pre-LWG2904 path.
Depends on D32671.
Reviewers: EricWF, CaseyCarter
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D33965
llvm-svn: 304891
Also: Move constexpr / triviality extension tests into the std tree and make them conditional on _LIBCPP_VERSION / _MSVC_STL_VERSION.
https://reviews.llvm.org/D32671
llvm-svn: 304847
This macro will instruct MSVC's STL to not warn about features that are deprecated in C++17,
as libcxx tests those features and uses them elsewhere.
llvm-svn: 304765
Was VSO#109062. This bug was filed *4 years ago*. I submitted a workaround to enable the scoped_allocator_adaptor tests to pass. Bug fixed a week and a half later. This was either a waste of my time, or I've discovered that libc++ has magical bugfix-inducing powers. My money's on the latter.
llvm-svn: 304730
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.
Reviewers: mclow.lists, bcraig, compnerd, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D33080
llvm-svn: 304357
The shell test versions didn't get all of the flags normal tests
do, specifically warning flags. This patch makes them .pass.cpp tests,
and uses a lit.local.cfg to add -fcoroutines-ts and to make them
UNSUPPORTED when that flag isn't available.
llvm-svn: 304351
from_address requires that the provided pointer refer to the suspended coroutine,
which doesn't have a type, or at least not one knowable by the user. Therefore
every use of `from_address` with a typed pointer is almost certainly a bug.
This behavior is a part of the TS specification, but hopefully it will be
in the future.
llvm-svn: 304172
More tests to come. I think that from_address overload should be deleted
or ill-formed, except for the 'void*' one; The user cannot possibly
have a typed pointer to the coroutine state.
llvm-svn: 304131
This patch adds end-to-end/breathing tests for coroutines
into libc++. The tests aren't specifically to test libc++ requirements
but instead are intented to ensure coroutines are working fine in general.
Although libc++ isn't exactly the most correct place for these tests
to live, there is one major advantage. The libc++ test suite is also
used by MSVC and by adding the tests here it ensures they will be
run against all currently available coroutine implementations.
llvm-svn: 304101
Clang supports coroutines in all dialects; Therefore libc++ should too,
otherwise the Clang extension is unusable.
I'm not convinced extending support to C++03 is a feasible long term
plan, since as the library grows to offer things like generators it
will be come increasingly difficult to limit the implementation to C++03.
However for the time being supporting C++03 isn't a big deal.
llvm-svn: 303963
Clang started providing -fcoroutines and defining __cpp_coroutines
way before it implemented the __builtin_coro_foo functions. This
means that simply checking if __cpp_coroutines is not a sufficient
way of detecting the actual feature.
This patch implements _LIBCPP_HAS_NO_COROUTINES which implements
a slightly more complex feature check. Specifically it requires
__cpp_coroutines >= 201703L, which only holds for Clang 5.0 built
after 2017/05/24.
llvm-svn: 303956
The tests were previously guarded by #if defined(_LIBCPP_VER) || defined(_MSVC_STL_VER),
which is both incorrect (e.g. _LIBCPP_VERSION) and unneeded. Although the tests are
technically non-standard (yet) they are supported by both libc++ and MSVC's STL.
libstdc++ doesn't regularly use the test suite so I'm not concerned about guarding these
tests for them.
llvm-svn: 303953
The original issues were caused because <experimental/coroutine>
didn't correctly #ifdef out enough of the header, which caused incomplete
types to be used.
This patch fixes the `#if defined(__cpp_coroutines)` guard and re-adds
the headers to the module map.
It also uglifies some incorrectly non-reserved names.
llvm-svn: 303936
This patch updates the promise() member to match the current spec.
Specifically it removes the non-const overload and make the return
type of the const overload non-const.
This patch also makes the ASSERT_NOT_NOEXCEPT tests libc++ specific,
since other implementations may be free to strengthen the specification.
llvm-svn: 303895
VSO#391542 "Types can't be convertible to nullptr_t"
Also put internal bug numbers on the workarounds in test_workarounds.h for correlation.
Differential Revision: https://reviews.llvm.org/D33290
llvm-svn: 303889
This C++17 Core Language feature isn't necessary when testing std::byte.
It's a minor convenience, but it limits test coverage to very new compilers.
This part activates the tests for more compilers.
llvm-svn: 302945
This C++17 Core Language feature isn't necessary when testing std::byte.
It's a minor convenience, but it limits test coverage to very new compilers.
This part changes the code.
Fixes D32386.
llvm-svn: 302944
This patch cleans up a number of issues reported by STL, including:
1) Fix duplicate is_convertible test.
2) Move non-standard reference_wrapper tests under test/libcxx
3) Fix assumption that sizeof(wchar_t) == 32 in the codecvt and
wstring_convert tests.
llvm-svn: 302870
This patch removes the clear() member from <string_view>. The
modifier was removed from the TS before it ever landed in the standard.
There is no reason libc++ should be providing this method.
llvm-svn: 302869
This patch attempts to make lookup_classname.pass.cpp usable against
other STL implementations by guarding the use of __regex_word. That being
said it seems likely that the test is still non-conforming due to how
libc++ handles the "w" character class.
llvm-svn: 302859
Some MinGW configurations use WinPThread instead of the native
threading interfaces. When this happens libc++ doesn't build because
it tries to use the wrong threading API.
This patch attempts to correctly detect and enable pthreads; Selecting
them when __MINGW32__ is defined and __has_include(<pthread.h>) is true.
I'm not sure if this works correctly 100% of the time but it seemed
like the most correct approach available.
llvm-svn: 302734
This patch follows up on feedback received in the review for
D32988. Specifically that libc++ should not mess with the
__builtin namespace, and that libc++ should use __popcnt to implement
__pop_count under MSVC.
llvm-svn: 302731
Summary:
This patch refactors and tries to remove as much of the Windows support headers as possible. This is needed because they currently introduce super weird include cycles and dependencies between STL and libc headers.
The changes in this patch are:
* remove `support/win32/support.h` completely. The required parts have either been moved into `support/win32/msvc_support.h` (for `MSVC` only helpers not needed by Clang), or directly into their respective `foo.h` headers.
* Combine `locale_win32.h` and `locale_mgmt_win32.h` into a single headers, this header should only be included within `__locale` or `locale` to avoid include cycles.
* Remove the unneeded parts of `limits_win32.h` and re-name it to `limits_msvc_win32.h` since it's only needed by Clang.
I've tested this patch using Clang on Windows, but I suspect it might technically regress our non-existent support for MSVC. Is somebody able to double check?
This refactor is needed to support upcoming fixes to `<locale>` on Windows.
Reviewers: bcraig, rmaprath, compnerd, EricWF
Reviewed By: EricWF
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D32988
llvm-svn: 302727
Clang 5.0 implements these changes here: 87cd035326
MSVC++ will implement these changes in the first toolset update to 2017.
Differential Revision: https://reviews.llvm.org/D33021
llvm-svn: 302710
Summary:
This patch fixes bugs.llvm.org/PR32979.
[util.smartptr.shared.const] says:
> In the constructor definitions below, enables shared_from_this with p, for a pointer p of type Y*, means
> that if Y has an unambiguous and accessible base class that is a specialization of enable_shared_from_-
> this.
This means that libc++ needs to respect the access specifier of the base class, and not attempt to construct
and enabled_shared_from_this base if it is private. However access specifiers don't affect overload resolution
so our current implementation will attempt to construct the private base.
This patch uses SFINAE to correctly detect if the shared_ptr input has an accessible enable_shared_from_this
base class.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33033
llvm-svn: 302709
This change works around a couple of bugs:
1. EDG doesn't like explicit constexpr in a derived class. This program:
struct Base {};
struct Derived : Base {
constexpr Derived() = default;
};
triggers "error: defaulted default constructor cannot be constexpr."
2. C1XX with /Za has no idea which constructor needs to be valid for copy elision.
The change also conditionally disables parts of the msvc_stdlib_force_include.hpp header that conflict with external configuration when _LIBCXX_IN_DEVCRT is defined.
Differential Revision: https://reviews.llvm.org/D32778
llvm-svn: 302707
I'm really lazy and the old name for the helper script
killed 2 letter tab completion for the include directory.
This patch renames it to avoid that problem and enable
lazyness.
llvm-svn: 302619
With the amount of work happening on Windows we should
have a MinGW bot to make sure we don't regress that functionality.
Currently it doesn't build :-(
llvm-svn: 302614
Previously, the force includes would complain about a missing _DEBUG symbol.
Now we dump macros before adding the force includes to the command line.
Now with proper newlines.
llvm-svn: 302497
This patch fixes the test failures and unexpected passes that occur
when testing against GCC 7. Specifically:
* don't mark __gcd as always inline because it's a recursive function. GCC diagnoses this.
* don't XFAIL the aligned allocation tests. GCC 7 supports them but not the -faligned-allocation option.
* Work around gcc.gnu.org/PR78489 in variants constructors.
llvm-svn: 302488
Previously <locale> used std::unique_ptr<remove_ptr<locale_t>, locale-mgmt-function>
as a scope guard for (A) creating new locales, and (B) setting the thread specific locale
in RAII safe manner.
However using unique_ptr has some problems, first it requires that locale_t is a pointer
type, which may not be the case (Windows will need a non-pointer locale_t type that emulates _locale_t).
The second problem is that users of the guards had to supply the locale management function to the custom
deleter at every call site. However these locale management functions don't exist natively Windows, making
a good Windows implementation of locale more difficult.
This patch creates distinct and simply RAII guards that replace unique_ptr. These guards handle calling
the correct locale management function so that callers don't have too. This simplification will
aid in upcoming Windows fixes.
llvm-svn: 302474
In T_size_size.pass, there is an explicit template argument to std::min to ask
for unsigned, to avoid type deduction errors. However, C1XX' warnings still
hate this use, because a 64 bit value (a size_t) is being passed to a function
accepting an unsigned (a 32 bit value).
Instead, change the tests to pass around std::size_t instances, and explicitly
narrow when constructing the string type under test. This also allows
removal of explicit template arguments to std::min.
llvm-svn: 302473
lcm.pass.cpp:
19: Update headers to that actually used in the test.
41: test0 was triggering narrowing warnings for all callers, because the
inputs were always ints, but some of the explicit template arguments were
smaller than that. Instead, have this function accept ints and static_cast
explicitly to the types we want before calling std::lcm.
47: Replace unnecessary ternary.
55: Use foo_t instead of typename foo<>::type
111/116: intX_t were not std::qualified but only <cfoo> headers were included.
141: C1XX has a bug where it interprets 2147483648 as unsigned int. Then the
negation trips "negation of unsigned value, result still unsigned" warnings.
Perma-workaround this issue by saying INT_MIN, which better documents the
intended behavior and avoids triggering warnings on C1XX.
gcd.pass.cpp:
Same changes as lcm.pass.cpp but for GCD.
llvm-svn: 302472
Previously, the force includes would complain about a missing _DEBUG symbol.
Now we dump macros before adding the force includes to the command line.
llvm-svn: 302421
Summary:
This patch implements exception_ptr on Windows using the `__ExceptionPtrFoo` functions provided by MSVC.
The `__ExceptionPtrFoo` functions are defined inside the C++ standard library, `msvcprt`, which is unfortunate because it requires libc++ to link to the MSVC STL. However this doesn't seem to cause any immediate problems. However to be safe I kept all usages within the libc++ dylib so that user programs wouldn't have to link to MSVCPRT as well.
Note there are still 2 outstanding exception_ptr/nested_exception test failures.
* `current_exception.pass.cpp` needs to be rewritten for the Windows exception_ptr semantics which copy the exception every time.
* `rethrow_if_nested.pass.cpp` need investigation. It hits a stack overflow, likely from recursion.
This patch also gets most of the `<future>` tests passing as well.
Reviewers: mclow.lists, compnerd, bcraig, rmaprath, majnemer, BillyONeal, STL_MSFT
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D32927
llvm-svn: 302393
Libc++ doesn't provide its own definitions of new/delete on Windows,
instead using the versions provided by VCRuntime. However VCRuntime
does not yet implement aligned new/delete so these tests fail.
It might be possible for libc++ to provide its own definitions only
for aligned new/delete as long as MSVC doesn't provide it. However
before this can be done libc++ needs to figure out how to implement
std::get_new_handler.
llvm-svn: 302384
This patch fixes test failures that occur on Windows because
the tests attempt to generate two distinct temp file names but
get the same name both time.
The fix for this is to create the first temp file before requesting
a second temporary file name. This ensures that the second name
will be unique.
llvm-svn: 302382
On Windows the function template `template <class T> void test()` has
the same mangled name when instantiated with the distinct types `void()`
and `void() noexcept`. When this occurs Clang emits an error. This error
was causing two type-traits tests to fail.
However this can be worked around by using class templates instead of
function templates, which is what this patch does to fix the errors.
llvm-svn: 302380
Summary:
In https://bugs.freebsd.org/207918, Daniel McRobb describes how using
std::showbase with ostreams can cause truncation of unsigned long long
when output format is octal. In fact, this can even happen with
unsigned int and unsigned long.
To ensure this does not happen, add one additional character to the
do_put buffers if std::showbase is on. Also add a test case.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D32670
llvm-svn: 302362
The ERROR_TIMEDOUT returned by the Windows API does not
have the same value as ETIMEDOUT. This caused condition_variable
to return timeouts as unknown errors.
llvm-svn: 302297
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.
See docs/DesignDocs/AvailabilityMarkup.rst for more information.
Differential Revision: https://reviews.llvm.org/D31739
llvm-svn: 302172
_HAS_CXX17 indicates whether MSVC's STL is in C++17 mode.
In MSVC there's a distinction between CRT headers like stdlib.h and STL headers
like cstdlib. Only the STL headers drag in yvals.h, our internal STL-wide header
that defines internal macros like _HAS_CXX17.
_HAS_CXX17 is an MSVC STL library macro, unconditionally defined. We centralize
everything on this, because we have to ask different questions to determine
whether C1XX, EDG, or Clang is in 14 or 17 mode, and we additionally permit
users to override the detection in one way (it's okay to ask for 17 from the
compiler, but only 14 from the libs, at least for the moment; only noexcept
in the type system will give us a headache).
As this header is for testing MSVC's STL, we can assume _HAS_CXX17 is defined.
Fixes D32726.
llvm-svn: 302104
r296685 started adding the test/ subdirectory even when
LIBCXX_INCLUDE_TESTS=OFF. This is great for testing libcxx standalone,
but it also breaks the build when the test/ subdirectory is removed
(and our submission system strips all test/ directories).
This patch updates the logic to check for test/ before adding it.
rdar://problem/31931366
llvm-svn: 302095
Summary: Seemed to have been overlooked in D24028.
This bug was found and brought to my attention by Paul Wankadia.
Reviewers: kubamracek, EricWF, dvyukov
Differential Revision: https://reviews.llvm.org/D32402
llvm-svn: 301132
For std::isinf, the standard requires effectively calling isinf as
double from Libc for integral types. But integral types are never
infinite; we don't need to call Libc to return false.
Also short-circuit other functions where Libc won't have interesting
answers: signbit, fpclassify, isfinite, isnan, and isnormal.
I added correctness tests for integral types since we're no longer
deferring to Libc.
In review it was pointed out that in future revisions of the C++
standard we may add more types to std::is_arithmetic (e.g.,
std::is_fixed_point). I'll leave it to a future commit to hack this to
allow using math functions on those. We'll need to change things like
__libcpp_fpclassify anyway, so I'm not sure anything here would really
be future-proof.
https://reviews.llvm.org/D31561
rdar://problem/31361223
llvm-svn: 301060
* Cover optional's emplace-from-initializer_list overload
* Verify that any::emplace and optional::emplace return a reference to the correct type even for throwing cases.
Differential Revision: https://reviews.llvm.org/D32106
llvm-svn: 301055
This patch XFAIL's a number of tests under test/libcxx when on Windows.
These failures need more investigation or patches to either Clang or libc++
but for now we don't want them to prevent the bot from going green.
llvm-svn: 300941
Summary:
libc++abi is never the right option for LIBCXX_TARGETING_MSVC, since it
targets the Itanium ABI, whereas MSVC uses the Microsoft ABI. Make the
default ABI be vcruntime when targeting MSVC even if libc++abi is
present in the tree.
Differential Revision: https://reviews.llvm.org/D32320
llvm-svn: 300921
Previously the ATOMIC_<TYPE>_LOCK_FREE macros were implemented
using __GCC_ATOMIC_<TYPE>_LOCK_FREE but GCC specific macros
are defined when -fms-compatibility is specified.
To avoid this Libc++ now tries to use the newly added
__CLANG_ATOMIC_<TYPE>_LOCK_FREE macros instead, and only falls
back to the GCC versions when the Clang ones aren't available.
llvm-svn: 300920
Previously both the static version of libc++ and the
import library for the DLL had the same name, 'c++.lib'.
This patch renames the static library on Windows to be `libc++.lib`
so it no longer conflicts. This naming convention is consistent with
other windows libraries.
llvm-svn: 300817
I'm currently trying to get a libc++ Windows builder working on appveyor.
This patch adds the configuration file needed to build libc++ on Appveyor.
Details of where the buildbot can be found will come later
llvm-svn: 300786
_LIBCPP_ABI_MICROSOFT is more appropriate to use here, since the
conditionals are controlling Microsoft mangling. It wasn't used
originally since it didn't exist at the time.
llvm-svn: 300743
Eric Fiselier