Bump version to 15.0.7

Bump version to 15.0.6

Bump version to 15.0.5

Bump version to 15.0.4

Bump version to 15.0.3

[libcxx] Make stdatomic.h work when included from a C source file

If a C source file includes the libc++ stdatomic.h, compilation will
break because (a) the C++ standard check will fail (which is ex

[libcxx] Make stdatomic.h work when included from a C source file

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

(cherry picked from commit afec0f0ec38a72bcc6a697c1cefb1dac0bbd02fb)

show more ...

Bump version to 15.0.2

[libc++] Keep unary_function and binary_function in C++17 for one more release

In LLVM 15, we added the deprecation markup for unary_function and
binary_function for >= C++11, and we also removed it

[libc++] Keep unary_function and binary_function in C++17 for one more release

In LLVM 15, we added the deprecation markup for unary_function and
binary_function for >= C++11, and we also removed it for >= C++17.
While this is in accordance with the Standard, it's also a bit quick
for our users, since there was no release in which the classes were
marked as deprecated before their removal.

We noticed widespread breakage due to this, and after months of trying
to fix downstream failures, I am coming to the conclusion that users
will be better served if we give them one release where unary_function
is deprecated but still provided even in >= C++17.

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

show more ...

[libcxx] Bump libc++ version to 15.0.1

[libc++] Take advantage of -fexperimental-library in libc++

When -fexperimental-library is passed, libc++ will now pick up the
appropriate __has_feature flag defined by Clang to enable the
experimen

[libc++] Take advantage of -fexperimental-library in libc++

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

show more ...

[libc++] Treat incomplete features just like other experimental features

In particular remove the ability to expel incomplete features from the
library at configure-time, since this can now be done

[libc++] Treat incomplete features just like other experimental features

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

show more ...

[libc++] Error if someone tries to use MSVC and tell them to contact the libc++ developers

Nobody knows if there are users of libc++ with MSVC. Let's try to find that out and encourage them to upstr

[libc++] Error if someone tries to use MSVC and tell them to contact the libc++ developers

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

show more ...

[libc++] Allow setting _LIBCPP_OVERRIDABLE_FUNC_VIS

Chromium changes this flag to be able to use a custom new/delete from a
dylib.

[libc++] Re-apply the use of ABI tags to provide per-TU insulation

This commit re-applies 9ee97ce3b830, which was reverted by 61d417ce
because it broke the LLDB data formatter tests. It also re-appl

[libc++] Re-apply the use of ABI tags to provide per-TU insulation

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

show more ...

Revert "[libc++] Use ABI tags instead of internal linkage to provide per-TU insulation"

This reverts commit 9ee97ce3b8305c5762ec34eecb4daf379984c95b.

[libc++] Use ABI tags instead of internal linkage to provide per-TU insulation

Instead of marking private symbols with internal_linkage (which leads to
one copy per translation unit -- rather wastef

[libc++] Use ABI tags instead of internal linkage to provide per-TU insulation

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

show more ...

[libc++] Use bounded iterators in std::span when the debug mode is enabled

Previously, we'd use raw pointers when the debug mode was enabled,
which means we wouldn't get out-of-range checking with s

[libc++] Use bounded iterators in std::span when the debug mode is enabled

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

show more ...

[libc++][AIX] Make basic_string layout compatible with earlier version

Summary:
Patch D123580 changed to use bit fields for strings in long and short mode. As a result, this changes the layout of th

[libc++][AIX] Make basic_string layout compatible with earlier version

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

show more ...

[libc++] Simplify the visibility attributes

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

[libc++] Complete the implementation of N4190

Fixes #37402

Reviewed By: ldionne

Spies: EricWF, avogelsgesang, libcxx-commits, arphaman

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

[libc++] Implement std::boyer_moore{, _horspool}_searcher

This mostly copys the `<experimental/functional>` stuff and updates the code to current libc++ style.

Reviewed By: ldionne, #libc

Spies: n

[libc++] Implement std::boyer_moore{, _horspool}_searcher

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

show more ...

[libc++] Simplify __config a bit

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

[libc++] Simplify __config a bit

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

show more ...

[libcxx] Fix allocator<void>::pointer in C++20 with removed members

When compiled with `-D_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS`
uses of `allocator<void>::pointer` resulted in compiler erro

[libcxx] Fix allocator<void>::pointer in C++20 with removed members

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

show more ...

[libc++] Remove macros for IBM compiler

It's not tested or used anymore -- instead a Clang-based compiler is
used on IBM nowadays.

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

[libc++][NFC] clang-format <__config>

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.s

[libc++][NFC] clang-format <__config>

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

show more ...