History log of /llvm-project-15.0.7/libcxx/include/future (Results 1 – 25 of 113)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# b48c5010 08-Jul-2022 Nikolas Klauser <[email protected]>

[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming

Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spie

[libc++] Make parameter names consistent and enforce the naming style using readability-identifier-naming

Ensure that parameter names have the style `__lower_case`

Reviewed By: ldionne, #libc

Spies: aheejin, sstefan1, libcxx-commits, miyuki

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

show more ...


# de4a57cb 27-Jun-2022 Louis Dionne <[email protected]>

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3

[libc++] Re-add transitive includes that had been removed since LLVM 14

This commit re-adds transitive includes that had been removed by
4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604,
and 489637e66dd3. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.

It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.

Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.

Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.

Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.

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

show more ...


Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4
# 1c4b31c3 18-May-2022 Louis Dionne <[email protected]>

[libc++] Improve error messages for disabled modes

We should not surface CMake-level options like LIBCXX_ENABLE_FILESYSTEM
to our users, since they don't know what it means. Instead, use a slightly

[libc++] Improve error messages for disabled modes

We should not surface CMake-level options like LIBCXX_ENABLE_FILESYSTEM
to our users, since they don't know what it means. Instead, use a slightly
more general wording.

Also, add an error in <ios> to improve the quality of errors for people
trying to use <iostream> when localization is disabled.

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

show more ...


Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1
# 385cc25a 25-Mar-2022 Louis Dionne <[email protected]>

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any publ

[libc++] Ensure that all public C++ headers include <__assert>

This patch changes the requirement for getting the declaration of the
assertion handler from including <__assert> to including any public
C++ header of the library. Note that C compatibility headers are
excluded because we don't implement all the C headers ourselves --
some of them are taken straight from the C library, like assert.h.

It also adds a generated test to check it. Furthermore, this new
generated test is designed in a way that will make it possible to
replace almost all the existing test-generation scripts with this
system in upcoming patches.

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

show more ...


Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# 52915d78 05-Mar-2022 Nikolas Klauser <[email protected]>

[libc++] Granularize <utility> includes

Reviewed By: ldionne, #libc

Spies: EricWF, libcxx-commits, arphaman

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


Revision tags: llvmorg-14.0.0-rc2
# 93b33390 11-Feb-2022 Mark de Wever <[email protected]>

[libc++] Remove _LIBCPP_HAS_NO_STRONG_ENUMS.

All supported compilers have implemented this feature.
Therefore use the language version instead of the feature macro.

Reviewed By: #libc, philnik, ldi

[libc++] Remove _LIBCPP_HAS_NO_STRONG_ENUMS.

All supported compilers have implemented this feature.
Therefore use the language version instead of the feature macro.

Reviewed By: #libc, philnik, ldionne, Quuxplusone

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

show more ...


# de462a43 23-Feb-2022 Nikolas Klauser <[email protected]>

[libc++] Remove <chrono> include from <future>

Reviewed By: Quuxplusone, #libc

Spies: libcxx-commits

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


# 489637e6 23-Feb-2022 Nikolas Klauser <[email protected]>

[libc++] Granularize chrono includes

Reviewed By: Quuxplusone, #libc

Spies: libcxx-commits

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


# f7558068 17-Feb-2022 Nikolas Klauser <[email protected]>

Remove __uncvref; use __uncvref_t instead

Reviewed By: Quuxplusone, #libc

Spies: libcxx-commits

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


# f87aa19b 14-Feb-2022 Louis Dionne <[email protected]>

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


Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init
# fa6b9e40 02-Feb-2022 Arthur O'Dwyer <[email protected]>

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

[libc++] Normalize all our '#pragma GCC system_header', and regression-test.

Now we'll notice if a header forgets to include this magic phrase.

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

show more ...


Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2
# bd6e6846 22-Dec-2021 Mark de Wever <[email protected]>

[libc++] Add the version header to all headers.

Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure

[libc++] Add the version header to all headers.

Some headers which require the version header depend on other headers to
provide it. Include the version header in all top-level headers to make
sure a header cleanup can't remove the version header.

Note this doesn't add the version header to the c headers.

Reviewed By: #libc, Quuxplusone, ldionne

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

show more ...


# cb8a0b07 14-Dec-2021 Arthur O'Dwyer <[email protected]>

[libc++] [ranges] Introduce _LIBCPP_AUTO_CAST(x) for auto(x).

Clang is gaining `auto(x)` support in D113393; sadly there
seems to be no feature-test macro for it. Zhihao is opening
a core issue for

[libc++] [ranges] Introduce _LIBCPP_AUTO_CAST(x) for auto(x).

Clang is gaining `auto(x)` support in D113393; sadly there
seems to be no feature-test macro for it. Zhihao is opening
a core issue for that macro.

Use `_LIBCPP_AUTO_CAST` where C++20 specifies we should use `auto(x)`;
stop using `__decay_copy(x)` in those places.
In fact, remove `__decay_copy` entirely. As of C++20, it's purely
a paper specification tool signifying "Return just `x`, but it was
perfect-forwarded, so we understand you're going to have to call
its move-constructor sometimes." I believe there's no reason we'd
ever need to do its operation explicitly in code.

This heisenbugs away a test failure on MinGW; see D112214.

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

show more ...


Revision tags: llvmorg-13.0.1-rc1
# eb8650a7 17-Nov-2021 Louis Dionne <[email protected]>

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


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3
# c8b14c03 27-Aug-2021 Louis Dionne <[email protected]>

[libc++][NFC] Fix include guard for decay_copy.h and remove underscores from the header

We don't use double underscores for private header names when they are
in a subdirectory with double underscor

[libc++][NFC] Fix include guard for decay_copy.h and remove underscores from the header

We don't use double underscores for private header names when they are
in a subdirectory with double underscores already.

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

show more ...


Revision tags: llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init
# 050b064f 01-Jul-2021 Christopher Di Bella <[email protected]>

[libcxx][functional][modular] splices <functional> into modular headers

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


Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2
# 6adbc83e 05-Jun-2021 Christopher Di Bella <[email protected]>

[libcxx][modularisation] moves <utility> content out of <type_traits>

Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges`

[libcxx][modularisation] moves <utility> content out of <type_traits>

Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`

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

show more ...


Revision tags: llvmorg-12.0.1-rc1
# bfbd73f8 19-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] Alphabetize and include-what-you-use. NFCI.

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


# 06b40e80 13-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] Alphabetize header inclusions and include-what-you-use <__debug>. NFCI.


# 4cd6ca10 20-Apr-2021 Louis Dionne <[email protected]>

[libc++] NFC: Normalize `#endif //` comment indentation


Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5
# 5c703f0f 01-Apr-2021 Marek Kurdej <[email protected]>

[libc++] Build and test with -Wundef warning. NFC.

This will avoid typos like `_LIBCPP_STD_VERS` (<future>) or using `#if TEST_STD_VER > 17` without including "test_macros.h".

Reviewed By: ldionne,

[libc++] Build and test with -Wundef warning. NFC.

This will avoid typos like `_LIBCPP_STD_VERS` (<future>) or using `#if TEST_STD_VER > 17` without including "test_macros.h".

Reviewed By: ldionne, #libc

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

show more ...


Revision tags: llvmorg-12.0.0-rc4
# 09a84d30 24-Mar-2021 jasonliu <[email protected]>

[libc++] Match declaration for non-member function std::swap(std::packaged_task) with what standard specify

Standard specifies:
```
template<class R, class... ArgTypes>
void swap(packaged_task<R(A

[libc++] Match declaration for non-member function std::swap(std::packaged_task) with what standard specify

Standard specifies:
```
template<class R, class... ArgTypes>
void swap(packaged_task<R(ArgTypes...)>& x, packaged_task<R(ArgTypes...)>& y) noexcept;
```

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

show more ...


Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2
# 781c476c 16-Dec-2020 Arthur O'Dwyer <[email protected]>

[libc++] ADL-proof vector<bool> by adding _VSTD:: qualification on calls.

This affects only vectors with weird/malicious allocators,
the same corner case covered in D91708, but for `vector<bool>` th

[libc++] ADL-proof vector<bool> by adding _VSTD:: qualification on calls.

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

show more ...


# be4c657b 12-Dec-2020 Arthur O'Dwyer <[email protected]>

[libc++] Consistently replace `::new(__p) T` with `::new ((void*)__p) T`. NFCI.

Everywhere, normalize the whitespace to `::new (EXPR) T`.
Everywhere, normalize the spelling of the cast to `(void*)EX

[libc++] Consistently replace `::new(__p) T` with `::new ((void*)__p) T`. NFCI.

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

show more ...


# d586f92c 27-Nov-2020 Arthur O'Dwyer <[email protected]>

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. T

[libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.

I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:

- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
This is the most common case.

- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
Leaving these as `_VSTD::allocator` would also be fine, but I decided
that removing the qualification is more consistent with existing practice.

- Names that specifically need un-versioned `std::` qualification,
or that I wasn't sure about. For example, I didn't touch any code in
<atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
and I didn't touch any instances of `std::type_info`.

In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.

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

show more ...


12345