[libc++] Refactor the configuration macros to being always defined (#112094)

This is a follow-up to #89178. This updates the `<__config_site>`
macros.

[libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] (#80455)

`[[__noreturn__]]` is now always available, so we can simply use the
attribute directly instead of through a macr

[libc++][NFC] Replace _LIBCPP_NORETURN and TEST_NORETURN with [[noreturn]] (#80455)

`[[__noreturn__]]` is now always available, so we can simply use the
attribute directly instead of through a macro.

show more ...

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmar

[libc++] Format the code base (#74334)

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

find libcxx/include libcxx/src -type f \
| grep -v 'module.modulemap.in' \
| grep -v 'CMakeLists.txt' \
| grep -v 'README.txt' \
| grep -v 'libcxx.imp' \
| grep -v '__config_site.in' \
| xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

[1]: https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all

show more ...

[libc++][hardening] Categorize more assertions.

Differential Revision: https://reviews.llvm.org/D155873

[libc++] Use _LIBCPP_VERBOSE_ABORT in a few remaining __throw_FOO functions

This provides better error messages when the program terminates due to
an exception being thrown in -fno-exceptions mode.

[libc++] Use _LIBCPP_VERBOSE_ABORT in a few remaining __throw_FOO functions

This provides better error messages when the program terminates due to
an exception being thrown in -fno-exceptions mode. Those seem to have
been missed in https://reviews.llvm.org/D141222.

Differential Revision: https://reviews.llvm.org/D154995

show more ...

[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.

This is done as a prerequisite to introducing hardened

[libc++][hardening][NFC] Introduce `_LIBCPP_ASSERT_UNCATEGORIZED`.

Replace most uses of `_LIBCPP_ASSERT` with
`_LIBCPP_ASSERT_UNCATEGORIZED`.

This is done as a prerequisite to introducing hardened mode to libc++.
The idea is to make enabling assertions an opt-in with (somewhat)
fine-grained controls over which categories of assertions are enabled.
The vast majority of assertions are currently uncategorized; the new
macro will allow turning on `_LIBCPP_ASSERT` (the underlying mechanism
for all kinds of assertions) without enabling all the uncategorized
assertions (in the future; this patch preserves the current behavior).

Differential Revision: https://reviews.llvm.org/D153816

show more ...

[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONS

Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`.

Reviewed By: ldionne, Mordante, #libc

Sp

[libc++][NFC] Rename _LIBCPP_NO_EXCEPTIONS to _LIBCPP_HAS_NO_EXCEPTIONS

Other macros that disable parts of the library are named `_LIBCPP_HAS_NO_WHATEVER`.

Reviewed By: ldionne, Mordante, #libc

Spies: libcxx-commits, smeenai

Differential Revision: https://reviews.llvm.org/D143163

show more ...

[libc++] Avoid instantiating type_trait classes

Use `using` aliases to avoid instantiating lots of types

Reviewed By: ldionne, #libc

Spies: libcxx-commits, miyuki

Differential Revision: https://r

[libc++] Avoid instantiating type_trait classes

Use `using` aliases to avoid instantiating lots of types

Reviewed By: ldionne, #libc

Spies: libcxx-commits, miyuki

Differential Revision: https://reviews.llvm.org/D132785

show more ...

[libc++][NFC] Whitespace refactoring of string.cpp for consistency and legibility

[libc++][NFC] Move definitions around in string.cpp to reduce _LIBCPP_HAS_NO_WIDE_CHARACTERS blocks

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional

[libc++] Move everything related solely to _LIBCPP_ASSERT to its own file

This is the first step towards disentangling the debug mode and assertions
in libc++. This patch doesn't make any functional change: it simply moves
_LIBCPP_ASSERT-related stuff to its own file so as to make it clear that
libc++ assertions and the debug mode are different things. Future patches
will make it possible to enable assertions without enabling the debug
mode.

Differential Revision: https://reviews.llvm.org/D119769

show more ...

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/inclu

[libc++] Replace `#include ""` with `<>` in libcxx/src/. NFCI.

Our best guess is that the two syntaxes should have exactly equivalent
effects, so, let's be consistent with what we do in libcxx/include/.

I've left `#include "include/x.h"` and `#include "../y.h"` alone
because I'm less sure that they're interchangeable, and they aren't
inconsistent with libcxx/include/ because libcxx/include/ never
does that kind of thing.

Also, use the `_LIBCPP_PUSH_MACROS/POP_MACROS` dance for `<__undef_macros>`,
even though it's technically unnecessary in a standalone .cpp file,
just so we have consistently one way to do it.

Differential Revision: https://reviews.llvm.org/D119561

show more ...

[libc++] Remove the std::string base class

Removing the base class of std::basic_string is not an ABI break, so we can remove any references to it from the header.

Reviewed By: ldionne, Mordante, #

[libc++] Remove the std::string base class

Removing the base class of std::basic_string is not an ABI break, so we can remove any references to it from the header.

Reviewed By: ldionne, Mordante, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D118733

show more ...

[libc++] Remove std::basic_string's base class in ABIv2

Remove `std::basic_string`'s base class in ABI version 2

Reviewed By: Quuxplusone, ldionne, #libc

Spies: libcxx-commits

Differential Revisi

[libc++] Remove std::basic_string's base class in ABIv2

Remove `std::basic_string`'s base class in ABI version 2

Reviewed By: Quuxplusone, ldionne, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D116334

show more ...

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste st

[runtimes][NFC] Remove filenames at the top of the license notice

We've stopped doing it in libc++ for a while now because these names
would end up rotting as we move things around and copy/paste stuff.
This cleans up all the existing files so as to stop the spreading
as people copy-paste headers around.

show more ...

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It

[libc++] Add an option to disable wide character support in libc++

Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.

Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.

Differential Revision: https://reviews.llvm.org/D111265

show more ...

[libc++] Refactor how basic_string and vector hoist exception-throwing functions

In basic_string and vector, we've been encapsulating all exception
throwing code paths in helper functions of a base

[libc++] Refactor how basic_string and vector hoist exception-throwing functions

In basic_string and vector, we've been encapsulating all exception
throwing code paths in helper functions of a base class, which are defined
in the compiled library. For example, __vector_base_common defines two
methods, __throw_length_error() and __throw_out_of_range(), and the class
is externally instantiated in the library. This was done a long time ago,
but after investigating, I believe the goal of the current design was to:

1. Encapsulate the code to throw an exception (which is non-trivial) in
an externally-defined function so that the important code paths that
call it (e.g. vector::at) are free from that code. Basically, the
intent is for the "hot" code path to contain a single conditional jump
(based on checking the error condition) to an externally-defined function,
which handles all the exception-throwing business.

2. Avoid defining this exception-throwing function once per instantiation
of the class template. In other words, we want a single copy of
__throw_length_error even if we have vector<int>, vector<char>, etc.

3. Encapsulate the passing of the container-specific string (i.e. "vector"
and "basic_string") to the underlying exception-throwing function
so that object files don't contain those duplicated string literals.
For example, we'd like to have a single "vector" string literal for
passing to `std::__throw_length_error` in the library, instead of
having one per translation unit.

However, the way this is achieved right now has two problems:

- Using a base class and exporting it is really weird - I've been confused
about this ever since I first saw it. It's just a really unusual way of
achieving the above goals. Also, it's made even worse by the fact that
the definitions of __throw_length_error and __throw_out_of_range appear
in the headers despite always being intended to be defined in the compiled
library (via the extern template instantiation).

- We end up exporting those functions as weak symbols, which isn't great
for load times. Instead, it would be better to export those as strong
symbols from the library.

This patch fixes those issues while retaining ABI compatibility (e.g. we
still export the exact same symbols as before). Note that we need to
keep the base classes as-is to avoid breaking the ABI of someone who
might inherit from std::basic_string or std::vector.

Differential Revision: https://reviews.llvm.org/D111173

show more ...

[libc++] NFC: Fix return-by-const-value and pass-by-const-value typos

While we can debate on the value of passing by const value, there is no
arguing that it's confusing to do so in some circumstanc

[libc++] NFC: Fix return-by-const-value and pass-by-const-value typos

While we can debate on the value of passing by const value, there is no
arguing that it's confusing to do so in some circumstances, such as when
marking a pointer parameter as being const (did you mean a pointer-to-const?).
This commit fixes a few issues along those lines.

show more ...

[libc++] Fix libc++ build with assertions enabled

This fixes http://llvm.org/PR50534. This is another take on D103960
which is less disruptive.

Differential Revision: https://reviews.llvm.org/D1039

[libc++] Fix libc++ build with assertions enabled

This fixes http://llvm.org/PR50534. This is another take on D103960
which is less disruptive.

Differential Revision: https://reviews.llvm.org/D103964

show more ...

Add flag _LIBCPP_ABI_STRING_OPTIMIZED_EXTERNAL_INSTANTIATIONS for basic_string ABI

Summary: This review is a mostly trivial change to use an explicit ABI flag for the unstable external template list

Add flag _LIBCPP_ABI_STRING_OPTIMIZED_EXTERNAL_INSTANTIATIONS for basic_string ABI

Summary: This review is a mostly trivial change to use an explicit ABI flag for the unstable external template list. This follows the practice for an ABI flag per feature, and provides a spot for the rational / motivation for the flag.

Reviewers: EricWF, ldionne

Subscribers: dexonsmith, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D75457

show more ...

Split _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a V1 and UNSTABLE version.

This change splits the _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a _LIBCPP_STRING_V1_EXTERN_TEMPLATE_LIST containing th

Split _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a V1 and UNSTABLE version.

This change splits the _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a _LIBCPP_STRING_V1_EXTERN_TEMPLATE_LIST containing the stable ABI, and a _LIBCPP_STRING_UNSTABLE_EXTERN_TEMPLATE_LIST containing the unstable ABI.

The purpose is to explicitly define and maintain the two lists, where the unstable ABI allows for ABI breaking changes for purposes such as optimization while offering a strong guarantee that any change inside the unstable ABI does not affect the stable ABI.

As per the comment in the __string header, we do still allow etries to be added to the stable ABI list as the c++ versions and corresponding c++ std API changes.

show more ...

[libc++] Explicitly enumerate std::string external instantiations - Attempt 2

The GCC build failures have been addressed, and the LLDB failures were
fixed by LLDB.

I have also verified that

[libc++] Explicitly enumerate std::string external instantiations - Attempt 2

The GCC build failures have been addressed, and the LLDB failures were
fixed by LLDB.

I have also verified that the apple-clang 9.0 segfault no longer
occurs.

Original Message:

The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.

This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.

Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.

(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.

show more ...

Revert "[libc++] Explicitly enumerate std::string external instantiations."

This is causing failures for multiple buildbots and bootstrap builds,
details at https://reviews.llvm.org/rG61bd1920.

Thi

Revert "[libc++] Explicitly enumerate std::string external instantiations."

This is causing failures for multiple buildbots and bootstrap builds,
details at https://reviews.llvm.org/rG61bd1920.

This reverts commit 61bd19206f61ace4b007838a2ff8884a13ec0374.

show more ...

[libc++] Explicitly enumerate std::string external instantiations.

The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can ca

[libc++] Explicitly enumerate std::string external instantiations.

The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.

This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.

Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.

(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.

show more ...

Recommit r362649, which was reverted in r262680 because of bugs in std::to_chars (which have now been fixed). Speedup to_string and to_wstring for integers using stack buffer and SSO

llvm-svn: 363003