It causes mysterious memory leaks when comparing std::string, see GitHub
Issue #60709 and the code review.
> All supported compilers support `consteval`, so there is no more need for the macro.
>
> Reviewed By: ldionne, Mordante, #libc
>
> Spies: libcxx-commits
>
> Differential Revision: https://reviews.llvm.org/D143489
This reverts commit aaef3b82f4f0dd3924a3491b381d5015ff472b86.
All supported compilers support `consteval`, so there is no more need for the macro.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D143489
As explained in a comment in https://reviews.llvm.org/D134124, we tried
landing this unconditionally but this actually bit some users who were
sharing std::unordered_map across an ABI boundary. This shows that the
ABI break is not benign and it should be guarded behind ABI v2.
Differential Revision: https://reviews.llvm.org/D143688
We renamed the `_LIBCPP_CONSTEXPR_` a while ago. This matches the change for `_LIBCPP_EXPLICIT_`.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D143165
Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`.
Reviewed By: ldionne, Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D143164
When support for declaring the c8rtomb() and mbrtoc8() functions within the
std namespace was added in commit 7e7013c5d4b1b3996c8dba668c5a94bb33b2999b,
internal glibc macros were used to determine if C2X extensions are enabled.
Specifically, a check for whether `__GLIBC_USE` is defined and whether
`__GLIBC_USE(ISOC2X)` is non-0 was added. `__GLIBC_USE` is an internal
detail of the glibc implementation that may be changed or removed in the
future potentially leading to inconsistency or compilation failures. This
change removes the use of the internal glibc macro to avoid such problems.
Unfortunately, without another mechanism to determine if C2X extensions are
enabled, this removal will result in inconsistent declarations of the
c8rtomb() and mbrtoc8() functions; when C++ char8_t support is not enabled, but
C2X extensions are, these functions will be declared in the global namespace
but not in the std namespace. This situation will improve when C23 support
is finalized and the check can be re-implemented using `__STDC_VERSION__`.
GCC rejects ABI tags on non mangled functions, as they would otherwise
be a no-op. This commit replaces such instances with equivalent
_LIBCPP_HIDE_FROM_ABI constants but without ABI tags attached.
.../include/c++/v1/__support/musl/xlocale.h:28:68: error: 'abi_tag'
attribute applied to extern "C" declaration 'long long int
strtoll_l(const char*, char**, int, locale_t)'
28 | strtoll_l(const char *__nptr, char **__endptr, int __base, locale_t) {
| ^
Bug: https://bugs.gentoo.org/869038
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D142415
There are no tests for the aliases because clang doesn't diagnose deprecated template aliases currently.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D127678
This allows clang to catch lifetime bugs through these functions.
As a drive-by, replace `_LIBCPP_INLINE_VISIBILITY` with `_LIBCPP_HIDE_FROM_ABI`.
Fixes#59900
Reviewed By: ldionne, #libc
Spies: rsmith, rnk, aaron.ballman, libcxx-commits
Differential Revision: https://reviews.llvm.org/D141321
Android only provides this function on API 28+; fix libc++ builds when
targeting older API levels.
Reviewed By: arichardson, #libc, philnik
Differential Revision: https://reviews.llvm.org/D141184
_LIBCPP_HIDE_FROM_ABI (which is what _LIBCPP_INLINE_VISIBILITY is) uses
ABI tags to avoid ODR violations when linking together object files
compiled against different versions of libc++. However, pointer
authentication uses the mangled name of the function to sign the
function pointer in the vtable, which means that the ABI tag effectively
changes how the pointers are signed.
This leads to PAC failures when passing an object that holds one of these
pointers in its vtable across an ABI boundary: one side will sign the
pointer using one function mangling (with one ABI tag), and the other
side will authenticate the pointer expecting it to have a different
mangled name, which won't work.
To make sure this does not regress in the future, this patch also adds
a clang-query test to detect incorrect applications of _LIBCPP_HIDE_FROM_ABI.
Differential Revision: https://reviews.llvm.org/D140453
C++17 defines the C11 `aligned_alloc`, so we can use that instead of
posix_memalign. This change allows building against picolibc without
defining _DEFAULT_SOURCE/_GNU_SOURCE.
The C11 `aligned_alloc` function should be available on all supported
non-Windows platforms except for macOS where we need version 10.15.
There is one caveat: aligned_alloc() requires that __size is a multiple of
__alignment, but [new.delete.general] only states "if the value of an
alignment argument passed to any of these functions is not a valid
alignment value, the behavior is undefined".
To handle calls such as ::operator new(1, std::align_val_t(128)), we
round up __size to __alignment (and check for wrap-around).
This is required at least for macOS where aligned_alloc(128, 1) returns
an error instead of allocating memory (glibc ignores the specification).
Differential Revision: https://reviews.llvm.org/D138196
This partly reverts D133535 and enables CTAD for more parts in format.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D135292
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
This is a re-application of the original patch by Eric Fiselier in
fcd549a7d828 which had been reverted due to reasons lost at this point.
I also added the macro to a few more types. Reviving this patch was
prompted by the discussion on https://llvm.org/D133425.
Differential Revision: https://reviews.llvm.org/D133535
If a C source file includes the libc++ stdatomic.h, compilation will
break because (a) the C++ standard check will fail (which is expected),
and (b) `_LIBCPP_COMPILER_CLANG_BASED` won't be defined because the
logic defining it in `__config` is guarded by a `__cplusplus` check, so
we'll end up with a blank header. Move the detection logic outside of
the `__cplusplus` check to make the second check pass even in a C context
when you're using Clang. Note that `_LIBCPP_STD_VER` is not defined when
in C mode, hence stdatomic.h needs to check if in C++ mode before using
that macro to avoid a warning.
In an ideal world, a C source file wouldn't be including the libc++
header directory in its search path, so we'd never have this issue.
Unfortunately, certain build environments make this hard to guarantee,
and in this case it's easy to tweak this header to make it work in a C
context, so I'm hoping this is acceptable.
Fixes https://github.com/llvm/llvm-project/issues/57710.
Differential Revision: https://reviews.llvm.org/D134591
It's been one and a half months now and nobody said anything, so I guess this code can be removed.
Reviewed By: ldionne, #libc
Spies: Mordante, libcxx-commits, mgorny, mstorsjo
Differential Revision: https://reviews.llvm.org/D132943
This change correct a configuration check that relies on the glibc __GLIBC_USE
macro being defined. Previously, the function-like macro was expanded without
ensuring it was actually defined. This resulted in compilation failures for
glibc versions prior to 2.25 (the glibc version in which the macro was added).
Differential Revision: https://reviews.llvm.org/D130946
This change implements the C library dependent portions of P0482R6
(char8_t: A type for UTF-8 characters and strings (Revision 6)) by
declaring std::c8rtomb() and std::mbrtoc8() in the <cuchar> header
when implementations are provided by the C library as specified by
WG14 N2653 (char8_t: A type for UTF-8 characters and strings
(Revision 1)) as adopted for C23.
A _LIBCPP_HAS_NO_C8RTOMB_MBRTOC8 macro is defined by the libc++ __config
header unless it is known that the C library provides these functions
in the current compilation mode. This macro is used for testing purposes
and may be of use to libc++ users. At present, the only C library known
to implement these functions is GNU libc as of its 2.36 release.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D130946
We've decided to use `_LIBCPP_STD_VER >= xy` while discussing to change the constexpr macros, so let's finally bump the version macro to match that.
Reviewed By: ldionne, Mordante, huixie90, #libc, avogelsgesang
Spies: avogelsgesang, libcxx-commits
Differential Revision: https://reviews.llvm.org/D133323
Adding `[[nodiscard]]` to functions is a conforming extension and done extensively in the MSVC STL.
Reviewed By: ldionne, EricWF, #libc
Spies: #libc_vendors, cjdb, mgrang, jloser, libcxx-commits
Differential Revision: https://reviews.llvm.org/D128267
This was discussed on Discord with the consensus that we should rename the macros.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D131498
When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.
Differential Revision: https://reviews.llvm.org/D132151
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, mgorny, arichardson
Differential Revision: https://reviews.llvm.org/D130905
When -fexperimental-library is passed, libc++ will now pick up the
appropriate __has_feature flag defined by Clang to enable the
experimental library features.
As a fly-by, also update the documentation for the various TSes.
Differential Revision: https://reviews.llvm.org/D130176
In particular remove the ability to expel incomplete features from the
library at configure-time, since this can now be done through the
_LIBCPP_ENABLE_EXPERIMENTAL macro.
Also, never provide symbols related to incomplete features inside the
dylib, instead provide them in c++experimental.a (this changes the
symbols list, but not for any configuration that should have shipped).
Differential Revision: https://reviews.llvm.org/D128928
Nobody knows if there are users of libc++ with MSVC. Let's try to find that out and encourage them to upstream their changes to make that configuration work.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D129055
This commit re-applies 9ee97ce3b830, which was reverted by 61d417ce
because it broke the LLDB data formatter tests. It also re-applies
6148c79a (the manual GN change associated to it).
Differential Revision: https://reviews.llvm.org/D127444
Instead of marking private symbols with internal_linkage (which leads to
one copy per translation unit -- rather wasteful), use an ABI tag that
gets rev'd with each libc++ version. That way, we know that we can't have
name collisions between implementation-detail functions across libc++
versions, so we'll never violate the ODR. However, within a single program,
each symbol still has a proper name with external linkage, which means
that the linker is free to deduplicate symbols even across TUs.
This actually means that we can guarantee that versions of libc++ can
be mixed within the same program without ever having to take a code size
hit, and without having to manually opt-in -- it should just work out of
the box.
Differential Revision: https://reviews.llvm.org/D127444
Previously, we'd use raw pointers when the debug mode was enabled,
which means we wouldn't get out-of-range checking with std::span's
iterators.
This patch introduces a new class called __bounded_iter which can
be used to wrap iterators and make them carry around bounds-related
information. This allows iterators to assert when they are dereferenced
outside of their bounds.
As a fly-by change, this commit removes the _LIBCPP_ABI_SPAN_POINTER_ITERATORS
knob. Indeed, not using a raw pointer as the iterator type is useful to
avoid users depending on properties of raw pointers in their code.
This is an alternative to D127401.
Differential Revision: https://reviews.llvm.org/D127418
Summary:
Patch D123580 changed to use bit fields for strings in long and short mode. As a result, this changes the layout of these strings on AIX because bit fields on AIX are 4 bytes, which breaks the ABI compatibility with earlier strings before the change on AIX. This patch uses the attribute 'packed' and anonymous structure to make string layout compatible. This patch will also make test cases alignof.compile.pass.cpp and sizeof.compile.pass.cpp introduced in D127672 pass on AIX.
Reviewed by: philnik, Mordante, hubert.reinterpretcast, libc++
Differential Revision: https://reviews.llvm.org/D128285
This mostly copys the `<experimental/functional>` stuff and updates the code to current libc++ style.
Reviewed By: ldionne, #libc
Spies: nlopes, adamdebreceni, arichardson, libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D121074
Simplify logic in `__config` by assuming that we are using Clang in C++03 mode. Also, use standardized feature-test macros instead of compiler-specific checks (like `__has_feature`) in a couple of places.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D127606
When compiled with `-D_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`
uses of `allocator<void>::pointer` resulted in compiler errors after D104323.
If we instantiate the primary template, `allocator<void>::reference` produces
an error 'cannot form references to void'.
To workaround this, allow to bring back the `allocator<void>` specialization by defining the new `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_VOID_SPECIALIZATION` macro.
To make sure the code that uses `allocator<void>` and the removed members does not break,
both `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` and `_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS` have to be defined.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D126210
It's not perfect, but it's a lot better than the status quo.
Reviewed By: ldionne, #libc
Spies: EricWF, aheejin, libcxx-commits, dschuff, krytarowski, fedor.sergeev, mstorsjo, phosek, abrachet
Differential Revision: https://reviews.llvm.org/D127644
This patch switches the build compiler for AIX from ibm-clang to clang. ibm-clang++_r has `-pthread` by default, but clang for AIX doesn't, so `-pthread` had to be added to the test config. A bunch of tests now pass, so the `XFAIL` was removed. This patch also switch the build to use the visibility support available in clang-15 to control symbols exported by the shared library (AIX traditionally uses explicit export lists for this purpose).
Reviewed By: #libc, #libc_abi, daltenty, #libunwind, ldionne
Differential Revision: https://reviews.llvm.org/D127470
