The bots were failing to build the cxx_filesystem target, so the
tests were failing. Though this does lead me to wonder how it
was ever working with c++experimental.
llvm-svn: 338095
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
Since r337668, we support statically linking dependencies only to shared
or static library. However, that change hasn't updated the check whether
to generate a linker script. We shouldn't generate linker script only in
the case when we aren't statically linked ABI into the shared library.
Differential Revision: https://reviews.llvm.org/D49834
llvm-svn: 338006
Summary:
Using int128_t with UBSAN causes link errors unless compiler-rt is providing the runtime library.
Specifically ubsan generates calls to __muloti4 but libgcc doesn't provide a definition.
In order to avoid this, and allow users to continue using sanitized versions of libc++, this patch introduces a hack.
It adds a cribbed version of the compiler-rt builtin to the libc++ filesystem sources.
I don't think this approach will work in the long run, but it seems OK for now.
Also see:
https://bugs.llvm.org/show_bug.cgi?id=30643https://bugs.llvm.org/show_bug.cgi?id=16404
Reviewers: mclow.lists, ldionne, rsmith, jyknight, echristo
Reviewed By: echristo
Subscribers: dberris, cfe-commits
Differential Revision: https://reviews.llvm.org/D49828
llvm-svn: 337990
This is a refinement on r337833. Previously we were installing two
copies of c++abi headers in libc++ build directory, one in
include/c++build and another one in include/c++/v1. However, the
second copy is unnecessary when building libc++ standalone.
Differential Revision: https://reviews.llvm.org/D49752
llvm-svn: 337979
-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
Eric Fiselier