llvm-project.git/libcxx/test/std/utilities/function.objects/bind/func.bind, branch main Unnamed repository; edit this file 'description' to name the repository. [libc++][modules] Fix missing and incorrect includes (#108850) 2024-09-16T19:06:20+00:00 Louis Dionne ldionne.2@gmail.com 2024-09-16T19:06:20+00:00 09e3a360581dc36d0820d3fb6da9bd7cfed87b5d This patch adds a large number of missing includes in the libc++ headers and the test suite. Those were found as part of the effort to move towards a mostly monolithic top-level std module. 
This patch adds a large number of missing includes in the libc++ headers
and the test suite. Those were found as part of the effort to move
towards a mostly monolithic top-level std module.
 [libc++] Make std::bind constexpr-friendly 2023-05-03T16:27:06+00:00 Louis Dionne ldionne.2@gmail.com 2023-04-26T21:08:18+00:00 13f5579caeee2c75baf1249b9f64de54f7c361e2 std::bind is supposed to be constexpr-friendly since C++20 and it was marked as such in our synopsis. However, the tests were not actually testing any of it and as it happens, std::bind was not really constexpr friendly. This fixes the issue and makes sure that at least some of the tests are running in constexpr mode. Some tests for std::bind check functions that return void, and those use global variables. These tests haven't been made constexpr-friendly, however the coverage added by this patch should be sufficient to get decent confidence. Differential Revision: https://reviews.llvm.org/D149295 
std::bind is supposed to be constexpr-friendly since C++20 and it was
marked as such in our synopsis. However, the tests were not actually
testing any of it and as it happens, std::bind was not really constexpr
friendly. This fixes the issue and makes sure that at least some of the
tests are running in constexpr mode.

Some tests for std::bind check functions that return void, and those
use global variables. These tests haven't been made constexpr-friendly,
however the coverage added by this patch should be sufficient to get
decent confidence.

Differential Revision: https://reviews.llvm.org/D149295
[libc++] Fix ODR violation with placeholders 2023-04-27T14:57:15+00:00 Louis Dionne ldionne.2@gmail.com 2023-04-26T20:35:13+00:00 77ac36547a2d15dc465d723179ce7047a59583ce In D145589, we made the std::bind placeholders inline constexpr to satisfy C++17. It turns out that this causes ODR violations since the shared library provides strong definitions for those placeholders, and the linker on Windows actually complains about this. Fortunately, C++17 only encourages implementations to use `inline constexpr`, it doesn't force them. So instead, we unconditionally define the placeholders as `extern const`, which avoids the ODR violation and is indistinguishable from `inline constexpr` for most purposes, since the placeholders are empty types anyway. Note that we could also go back to the pre-D145589 state of defining them as non-inline constexpr variables in C++17, however that is definitely non-conforming since that means the placeholders have different addresses in different TUs. This is all a bit pedantic, but all in all I feel that `extern const` provides the best bang for our buck, and I can't really find any downsides to that solution. Differential Revision: https://reviews.llvm.org/D149292 
In D145589, we made the std::bind placeholders inline constexpr to
satisfy C++17. It turns out that this causes ODR violations since the
shared library provides strong definitions for those placeholders, and
the linker on Windows actually complains about this.

Fortunately, C++17 only encourages implementations to use `inline constexpr`,
it doesn't force them. So instead, we unconditionally define the placeholders
as `extern const`, which avoids the ODR violation and is indistinguishable
from `inline constexpr` for most purposes, since the placeholders are
empty types anyway.

Note that we could also go back to the pre-D145589 state of defining them
as non-inline constexpr variables in C++17, however that is definitely
non-conforming since that means the placeholders have different addresses
in different TUs. This is all a bit pedantic, but all in all I feel that
`extern const` provides the best bang for our buck, and I can't really
find any downsides to that solution.

Differential Revision: https://reviews.llvm.org/D149292
[libc++] Fix "size_t" constants that should be "bool" or "int", and add tests 2023-02-27T21:53:04+00:00 Arthur O'Dwyer arthur.j.odwyer@gmail.com 2023-01-19T22:10:09+00:00 049a3fe10f644c259a33f185a0a7711757252188 `is_placeholder`, despite having an "is_" name, actually returns an int: 1 for `_1`, 2 for `_2`, 3 for `_3`, and so on. But it should still be int, not size_t. 
`is_placeholder`, despite having an "is_" name, actually returns an int:
1 for `_1`, 2 for `_2`, 3 for `_3`, and so on. But it should still be int,
not size_t.
[libc++] Avoid including <tuple> in compressed_pair.h 2022-09-18T08:49:35+00:00 Nikolas Klauser nikolasklauser@berlin.de 2022-09-17T12:30:29+00:00 7afa1598a38103f9b940f219d7c2bef578139e94 compressed_pair is widely used in the library, but most of the uses don't use the tuple parts. To avoid including <tuple> everywhere, use the forward declaration instead in compressed_pair.h Reviewed By: ldionne, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D133331 
compressed_pair is widely used in the library, but most of the uses don't use the tuple parts. To avoid including <tuple> everywhere, use the forward declaration instead in compressed_pair.h

Reviewed By: ldionne, #libc

Spies: libcxx-commits

Differential Revision: https://reviews.llvm.org/D133331
[libc++][AIX] Use C++ overloads from libc++'s math.h 2022-03-01T20:53:41+00:00 David Tenty daltenty@ibm.com 2022-02-07T23:22:35+00:00 f642436cc213f99a90e3a4258666dd693b29d79d AIX's system header provides these C++ overloads for compatibility with older XL C++ implementations, but they can be disabled by defining __LIBC_NO_CPP_MATH_OVERLOADS__ since AIX 7.2 TL 5 SP 3. Since D109078 landed clang will define this macro when using libc++ on AIX and we already run the lit tests with it too. This change will enable the overloads in libc++'s math.h and we'll continue to require the compiler to define the macro going forward. Reviewed By: ldionne, jsji, EricWF Differential Revision: https://reviews.llvm.org/D102172 co-authored-by: Jason Liu <jasonliu.development@gmail.com> 
AIX's system header provides these C++ overloads for compatibility with
older XL C++ implementations, but they can be disabled by defining
__LIBC_NO_CPP_MATH_OVERLOADS__ since AIX 7.2 TL 5 SP 3.

Since D109078 landed clang will define this macro when using libc++ on
AIX and we already run the lit tests with it too. This change will
enable the overloads in libc++'s math.h and we'll continue to require
the compiler to define the macro going forward.

Reviewed By: ldionne, jsji, EricWF

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

co-authored-by: Jason Liu <jasonliu.development@gmail.com>
[libc++][NFC] Fix placement of some XFAILs 2022-01-13T20:28:41+00:00 Louis Dionne ldionne.2@gmail.com 2022-01-13T20:28:26+00:00 3d4050816905da971a31957697cfde0856936db4 






[libc++] Properly handle specializations of std::is_placeholder.
2022-01-10T17:38:59+00:00

Arthur O'Dwyer
arthur.j.odwyer@gmail.com

2021-12-30T01:45:08+00:00

07a0b0ee94880cc193f3c63ebe3c4662c3123606

Before this patch, the user needed to specialize both of
`is_placeholder<MyType>` and `is_placeholder<const MyType>`.
After this patch, only the former is needed (although the
latter is harmless if provided).

The new tests don't actually fail unless return type deduction
is used, which is a C++14 feature. Specializing `is_placeholder`
is still allowed in C++11, though.

Fixes #51095.

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





Before this patch, the user needed to specialize both of
`is_placeholder<MyType>` and `is_placeholder<const MyType>`.
After this patch, only the former is needed (although the
latter is harmless if provided).

The new tests don't actually fail unless return type deduction
is used, which is a C++14 feature. Specializing `is_placeholder`
is still allowed in C++11, though.

Fixes #51095.

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







[libc++] Always define a key function for std::bad_function_call in the dylib
2021-11-16T19:23:27+00:00

Konstantin Varlamov
varconst@apple.com

2021-11-15T20:40:55+00:00

434dc0a5bcae50e87458e893ae5469619a35839e

However, whether applications rely on the std::bad_function_call vtable
being in the dylib is still controlled by the ABI macro, since changing
that would be an ABI break.

Also separate preprocessor definitions for whether to use a key function
and whether to use a `bad_function_call`-specific `what` message
(`what` message is mandated by [LWG2233](http://wg21.link/LWG2233)).

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





However, whether applications rely on the std::bad_function_call vtable
being in the dylib is still controlled by the ABI macro, since changing
that would be an ABI break.

Also separate preprocessor definitions for whether to use a key function
and whether to use a `bad_function_call`-specific `what` message
(`what` message is mandated by [LWG2233](http://wg21.link/LWG2233)).

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







[libc++][CI] Add AIX pipeline config
2021-11-08T15:30:27+00:00

David Tenty
daltenty@ibm.com

2021-10-19T18:09:46+00:00

28b3cac7cf403bfc824299087a7420783c2d9311

This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing tests which remain to be investigated on AIX, so that the CI produces a clean build.

Reviewed By: #libc, ldionne

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





This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing tests which remain to be investigated on AIX, so that the CI produces a clean build.

Reviewed By: #libc, ldionne

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