| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In 7cd67904f776, we removed the unnecessary nullptr checks from the libc++abi
definition of operator delete, but we forgot to update the definition in
libc++ (damn code duplication!). Then, in d4a1e03c5fb5, I synced the
definitions across libc++ and libc++abi, but I did it the wrong way around.
I re-added the if() checks to libc++abi instead of removing them from libc++.
In ef74f0fdc339, we re-removed the if() check from operator delete, but
only in libc++abi. This patch corrects this mess and removes it
consistently in libc++ and libc++abi.
Differential Revision: https://reviews.llvm.org/D93473
|
|
allocate_shared
This patch updates `allocate_shared` to call `allocator_traits::construct`
when creating the object held inside the shared_pointer, and
`allocator_traits::destroy` when destroying it. This resolves
the part of P0674R1 that was originally filed as LWG2070.
This change is landed separately from the rest of P0674R1 because it is
incredibly tricky from an ABI perspective.
This is the reason why this change is so tricky is that we previously
used EBO in a compressed pair to store both the allocator and the object
type stored in the `shared_ptr`. However, starting in C++20, P0674
requires us to use Allocator construction for initializing the object type.
That requirement rules out the use of the EBO for the object type, since
using the EBO implies that the base will be initialized when the control
block is initialized (and hence we can't do it through Allocator construction).
Hence, supporting P0674 requires changing how we store the object type
inside the control block, which we do while being ABI compatible by using
some trickery with a properly aligned char buffer.
Fixes https://llvm.org/PR41900
Supersedes https://llvm.org/D62760
Differential Revision: https://reviews.llvm.org/D91201
|
|
* Add feature test macros.
* Add buildbot configuration generic-cxx2b that uses clang-tot.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D94227
|
|
It's still a little confusing because in many cases C++17 and C++20
have different values, and libc++ implements the C++17 behavior but
not the C++20 behavior; 'unimplemented' can't represent that scenario.
Ultimately we probably ought to completely redesign the script to be
in terms of paper numbers, rather than language revisions, and make
it generate the CSV files like "Cxx2aStatusPaperStatus.csv" as well.
Most newly added macros are unimplemented. I've marked a few as implemented,
though, based on my reading of the code; for example I was pretty sure
`__cpp_lib_latch` is implemented since we have `<latch>`.
Differential Revision: https://reviews.llvm.org/D93830
|
|
FreeBSD did not provide the __atomic_* functions as part of the base
system until recently. They were added to libgcc_s in SVN revision r364753
(August 2020), so check for availability of 'non-lockfree-atomics' so that
these tests do not fail unexpectedly on older versions of FreeBSD.
This also removes the #ifndef __APPLE__ from atomic_helpers.h that was used
to work around lack of atomic runtime functions on older Apple platforms
and replaces it with XFAIL: !non-lockfree-atomics.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88818
|
|
For ease of comparing our list with the official SD-6 list, which is alphabetized.
https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations#library-feature-test-macros
This also alphabetizes the lists of headers in which the macros are
defined, which harmlessly alters many comments in <version>.
Also drive-by-fix some trivial flake8 warnings.
|
|
The installation directory was never meant to contain a brace.
|
|
* The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9).
* Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b).
That's a preparation step to add c++2b support to libc++.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93383
|
|
The nullptr_t_integral_cast.pass.cpp test is currently xfailed for
C++03, but actually, it only fails with the first version of libc++
ABI.
This patch changes XFAIL to UNSUPPORTED to avoid unexpected passes
with ABI v2 or later.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93941
|
|
* Check created symlinks.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93520
|
|
Differential Revision: https://reviews.llvm.org/D91138
|
|
This affects only vectors with weird/malicious allocators,
the same corner case covered in D91708, but for `vector<bool>` this time.
Also ADL-proof <__tree>, which affects only sets and maps with weird/malicious
allocators where the ADL trap is in the *fancy pointer type*.
Also drive-by _VSTD:: qualification in the guts of std::bind,
std::packaged_task, std::condition_variable.
Differential Revision: https://reviews.llvm.org/D93424
|
|
|
|
"LLVM Buildbot on libcxx-libcxxabi-libunwind-armv7-linux" is not happy
with comparing `unsigned` and `int` [-Werror,-Wsign-compare].
|
|
"LLVM Buildbot on libcxx-libcxxabi-x86_64-linux-debian" is not happy
with default-initializing the `double` member of `A` in a constexpr
function. At least I'm pretty sure that's what it's complaining about.
|
|
default_searcher.
This completes the implementation of P1065 "constexpr INVOKE":
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1065r2.html
This doesn't yet complete the implementation of P1032 "Misc constexpr bits,"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1032r1.html
but it does complete all of the <functional> bits, which means
that we can now set `__cpp_lib_constexpr_functional` for C++20.
This could use more constexpr tests for `std::reference_wrapper<T>`,
but the existing tests are extremely non-constexpr-friendly and
so I don't want to get into that rabbit-hole today.
Differential Revision: https://reviews.llvm.org/D93815
|
|
We don't need to use global variables here; we can store the "State"
of this machinery on the stack, so that it's constexpr-friendly.
|
|
On macOS 10.14 /usr/lib/system/libcompiler_rt.dylib contains all the
`__atomic_load*`, etc. functions but does not include the `__atomic_is_lock_free`
function. The lack of this function causes the non-lockfree-atomics feature
to be set to false even though large atomic operations are actually
supported, it's just the is_lock_free() function that is missing.
This is required so that the !non-lockfree-atomics feature can be used
to XFAIL tests that require runtime library support (D88818).
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D91911
|
|
|
|
The directory_iterator.cpp file did contain an incomplete,
non-working implementation for windows.
Change it to use the wchar version of the APIs.
Don't set the windows specific errors from GetLastError() as code
in the generic category; remap the errors to the std::errc values.
Error out cleanly on empty paths.
Invoke FindFirstFile on <directoryname>/* to actually list the
entries of the directory.
If the first entry retured by FindFirstFile is to be skipped (e.g.
being "." or ".."), call advance() (which calls FindNextFile and loops)
which doesn't return until a valid entry is found (or the end is
reached).
Differential Revision: https://reviews.llvm.org/D91140
|
|
on windows
On windows, the narrow, char based paths normally don't use utf8, but
can use many different native code pages, and this is what system
functions that operate on files, taking such paths/file names, interpret
them as.
Differential Revision: https://reviews.llvm.org/D91137
|
|
readable. NFC.
Differential Revision: https://reviews.llvm.org/D91136
|
|
Also set the preferred separator to backslash.
libc++ doesn't compile successfully for windows prior to this change,
and this change on its own isn't enough to make it compile successfully
either, but is the first stepping stone towards making it work correctly.
Most of operations.cpp will need to be touched, both for calling
functions that take wchar paths, but also for using other windows
specific functions instead of the posix functions used so far; that is
handled in later commits.
Changing parts of operations.cpp to generalize the string type handling
in code that doesn't touch system functions.
Differential Revision: https://reviews.llvm.org/D91135
|
|
gcc supports it only at the beginning:
$ g++ -o /dev/null -c /tmp/test_extern.cpp
$ cat /tmp/test_extern.cpp
extern "C" __attribute__ ((__visibility__("default"))) int foo();
Otherwise:
$ g++ -o /dev/null -c /tmp/test_extern.cpp
/tmp/test_extern.cpp:1:52: error: expected unqualified-id before string constant
1 | __attribute__ ((__visibility__("default"))) extern "C" int foo();
| ^~~
$ cat /tmp/test_extern.cpp
__attribute__ ((__visibility__("default"))) extern "C" int foo();
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D93316
|
|
Differential Revision: https://reviews.llvm.org/D93283
|
|
Installing clang-format-11 doesn't seem to work if it's done before
we've installed LLVM. I must admit I didn't try to get to the bottom
of the issue, since installing it after seems to work.
|
|
Two problems fixed:
* an old version of clang-format get installed by default (6.0).
* git-clang-format is not present, only git-clang-format-<version> (e.g. git-clang-format-6.0).
Solution:
* install clang-format-11 with explicit version
* make symlink git-clang-format to the latest version of git-clang-format-<version>
Differential Revision: https://reviews.llvm.org/D93201
|
|
|
|
|
|
When the allocator is only explicitly convertible from other specializations
of itself, the new version of std::allocate_shared would not work because
it would try to do an implicit conversion. This patch fixes the problem
and adds a test so that we don't fall into the same trap in the future.
|
|
Checking that `T` is constructible from `Args...` is technically not
required by the Standard, although any implementation will obviously
error out if that's not satisfied. However, this check is incompatible
with using Allocator construction in the control block (upcoming change
as part of implementing P0674), so I'm removing it now to reduce the
upcoming diff as much as possible.
Differential Revision: https://reviews.llvm.org/D93246
|
|
helper method
This makes __get_alloc consistent with __get_elem, and will reduce the
diff required to implement P0674R1.
|
|
This commit is a step towards making it easier to add support for arrays
in allocate_shared. Adding support for arrays will require writing multiple
functions, and the current complexity of writing allocate_shared is
prohibitive for understanding.
Differential Revision: https://reviews.llvm.org/D93130
|
|
In addition to making the code a lot easier to grasp by localizing many
helper functions to the only file where they are actually needed, this
will allow creating helper functions that depend on allocator_traits
outside of <memory>.
This is done as part of implementing array support in allocate_shared,
which requires non-trivial array initialization algorithms that would be
better to keep out of <memory> for sanity. It's also a first step towards
splitting up our monolithic headers into finer grained ones, which will
make it easier to reuse functionality across the library. For example,
it's just weird that we had to define `addressof` inside <type_traits>
to avoid circular dependencies -- instead it's better to implement those
in true helper headers.
Differential Revision: https://reviews.llvm.org/D93074
|
|
- std::reference_wrapper
- std::function
- std::mem_fn
While I'm here, remove _VSTD:: qualification from calls to `declval`
because it takes no arguments and thus isn't susceptible to ADL.
Differential Revision: https://reviews.llvm.org/D92884
|
|
Everywhere, normalize the whitespace to `::new (EXPR) T`.
Everywhere, normalize the spelling of the cast to `(void*)EXPR`.
Without the cast to `(void*)`, the expression triggers ADL on GCC.
(I think this is a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249)
Even if it doesn't trigger ADL, it still seems incorrect to use any argument
that's not exactly `(void*)` because that opens the possibility of overload
resolution picking a user-defined overload of `operator new`, which would be
wrong.
Differential Revision: https://reviews.llvm.org/D93153
|
|
That's a follow-up patch after D92769.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93026
|
|
Otherwise they come out in random (inode?) order.
Also `chmod +x` the generator, and re-run it. Somehow on Marek's
machine it produced \r\n line endings?! Open all files with
`newline='\n'` so that (if the Python3 docs are correct)
that won't happen again.
Differential Revision: https://reviews.llvm.org/D93137
|
|
|
|
This type has been unused since commit 5b4cc84b87232e67afb63e2bad429b3211b26964.
|
|
|
|
|
|
|
|
|
|
|
|
TARGET_SONAME_FILE isn't valid on Windows, and TARGET_FILE should achieve
the same results.
Differential Revision: https://reviews.llvm.org/D92856
|
|
This simplifies the implementation, and it appears to be equivalent since
make_shared was allocating memory with std::allocator anyway.
Differential Revision: https://reviews.llvm.org/D93071
|
|
`_LIBCPP_STD_VER` can never be less than 11.
The relevant part of `__config` is:
```
#ifndef _LIBCPP_STD_VER
# if __cplusplus <= 201103L
# define _LIBCPP_STD_VER 11
```
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93025
|
|
Generally these calls aren't vulnerable to ADL because they involve only
primitive types. The ones in <list> and <vector> drag in namespace std
but that's OK; the ones in <fstream> and <strstream> are vulnerable
iff `CharT` is an enum type, which seems far-fetched.
But absolutely zero of them *need* ADL to happen; so in my opinion
they should all be consistently qualified, just like calls to any
other (non-user-customizable) functions in namespace std.
Also: Include <cstring> and <cwchar> in <__string>.
We seemed to be getting lucky that <memory> included <iterator>
included <iosfwd> included <wchar.h>. That gave us the
global-namespace `wmemmove`, but not `_VSTD::wmemmove`.
This is now fixed.
I didn't touch these headers:
<ext/__hash> uses strlen, safely
<support/ibm/locale_mgmt_aix.h> uses memcpy, safely
<string.h> uses memchr and strchr, safely
<wchar.h> uses wcschr, safely
<__bsd_locale_fallbacks.h> uses wcsnrtombs, safely
Differential Revision: https://reviews.llvm.org/D93061
|
|
This matches how libc++ does it in all other C++ headers
(that is, headers not ending in ".h").
We need to include <cstring> if we want to use `_VSTD::memmove`
instead of unqualified ADL `memmove`. Even though ADL doesn't
physically matter in <charconv>'s specific case, I'm trying
to migrate libc++ to using `_VSTD::memmove` for all cases
(because some of them do matter, and this way it's easier to
grep for outliers).
Differential Revision: https://reviews.llvm.org/D92875
|
