History log of /llvm-project-15.0.7/libcxx/include/valarray (Results 1 – 25 of 68)
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
# 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
# db1978b6 16-Jun-2022 Nikolas Klauser <[email protected]>

[libc++] Mark standard-mandated includes as such

Reviewed By: ldionne, Mordante, #libc, saugustine

Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman

Differential

[libc++] Mark standard-mandated includes as such

Reviewed By: ldionne, Mordante, #libc, saugustine

Spies: saugustine, MaskRay, arichardson, mstorsjo, jloser, libcxx-commits, arphaman

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

show more ...


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2
# 2ae52326 08-Jun-2021 Louis Dionne <[email protected]>

[libc++] Towards a simpler extern template story in libc++

The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for

[libc++] Towards a simpler extern template story in libc++

The flexibility around extern template instantiation declarations in
libc++ result in a very complicated model, especially when support for
slightly different configurations (like the debug mode or assertions
in the dylib) are taken into account. That results in unexpected bugs
like http://llvm.org/PR50534 (and there have been multiple similar
bugs in the past, notably around the debug mode).

This patch gets rid of the _LIBCPP_DISABLE_EXTERN_TEMPLATE knob, which
I don't think is fundamental. Indeed, the motivation for that knob was to
avoid taking a dependency on the library, however that can be done better
by linking against the static library instead. And in fact, some parts of
the headers will always depend on things defined in the library, which
defeats the original goal of _LIBCPP_DISABLE_EXTERN_TEMPLATE.

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

show more ...


# b8f6f9e7 05-May-2022 Louis Dionne <[email protected]>

[libc++] Avoid creating temporaries in unary expressions involving valarray

Currently, unary expressions involving valarray will create a temporary.
This leads to dangling references in expressions

[libc++] Avoid creating temporaries in unary expressions involving valarray

Currently, unary expressions involving valarray will create a temporary.
This leads to dangling references in expressions like `-a * b`, because
`-a` is a temporary and the resulting expression will refer to it. This
patch fixes the problem by creating a lazy expression to perform the unary
operation instead of eagerly creating a temporary valarray. This is
permitted by the Standard, which does not specify the exact type of
most expressions involving valarrays.

This is technically an ABI break, however I believe the actual potential
for breakage is very low.

rdar://90152242

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

show more ...


# a83f4b9c 23-Apr-2022 Nikolas Klauser <[email protected]>

[libc++] Remove <functional> includes

Reviewed By: var-const, #libc, ldionne

Spies: #libc_vendors, ldionne, libcxx-commits, miyuki

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


# faef447e 17-Apr-2022 Nikolas Klauser <[email protected]>

[libc++] Granularize <functional> includes

Reviewed By: Mordante, #libc

Spies: libcxx-commits, miyuki

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


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


# 48f8a7c4 25-Feb-2022 Corentin Jabot <[email protected]>

[libc++] Make sure calls to std::move are always qualified

This fixes instances of the newly added `-Wunqualified-std-cast-call`.

(Commit 7853371146 removed unqualified `move` from the tests,
but t

[libc++] Make sure calls to std::move are always qualified

This fixes instances of the newly added `-Wunqualified-std-cast-call`.

(Commit 7853371146 removed unqualified `move` from the tests,
but these unqualified `move`s remained undetected in the actual headers.)

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

show more ...


# 2e2f3158 15-Feb-2022 Nikolas Klauser <[email protected]>

[libc++] Granularize algorithm includes

Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

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

[libc++] Granularize algorithm includes

Reviewed By: Mordante, ldionne, Quuxplusone, #libc, #libc_abi

Spies: #libc_vendors, libcxx-commits, miyuki

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

show more ...


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


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


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


# f9f97cae 28-Oct-2021 Konstantin Varlamov <[email protected]>

[libc++] P0433R2: add the remaining deduction guides.

Add deduction guides to `valarray` and `scoped_allocator_adaptor`. This largely
finishes implementation of the paper:

* deduction guides for ot

[libc++] P0433R2: add the remaining deduction guides.

Add deduction guides to `valarray` and `scoped_allocator_adaptor`. This largely
finishes implementation of the paper:

* deduction guides for other classes mentioned in the paper were
implemented previously (see the list below);
* deduction guides for several classes contained in the proposal
(`reference_wrapper`, `lock_guard`, `scoped_lock`, `unique_lock`,
`shared_lock`) were removed by [LWG2981](https://wg21.link/LWG2981).

Also add deduction guides to the synopsis for the few classes (e.g. `pair`)
where they were missing.

The only part of the paper that isn't fully implemented after this patch is
making sure certain deduction guides don't participate in overload resolution
when given incorrect template parameters.

List of significant commits implementing the other parts of P0433 (omitting some
minor fixes):

* [pair](https://github.com/llvm/llvm-project/commit/af65856eec160d163c764faad250d93357be7c83)
* [basic_string](https://github.com/llvm/llvm-project/commit/6d9f750dec29e8ae5366092e64cd343dae2c7464)
* [array](https://github.com/llvm/llvm-project/commit/0ca8c0895c6034615593c295dd955f29b25bf3d4)
* [deque](https://github.com/llvm/llvm-project/commit/dbb6f8a8179b0604e25707b5c1b72be6164f62d9)
* [forward_list](https://github.com/llvm/llvm-project/commit/e076700b7786959206acef136ecf05d54078e4e1)
* [list](https://github.com/llvm/llvm-project/commit/4a227e582b2f13880ea049b29988a37a0f7c0742)
* [vector](https://github.com/llvm/llvm-project/commit/df8f75479278d5ce16eede342ceb5ba2fd71460b)
* [queue/stack/priority_queue](https://github.com/llvm/llvm-project/commit/5b8b8b5dce587f1e5a4a31cc24f09b18bd53ff9a)
* [basic_regex](https://github.com/llvm/llvm-project/commit/edd5e29cfe9f67ec8e7e0eda12eb05e616fdeebc)
* [optional](https://github.com/llvm/llvm-project/commit/f35b4bc3954f3b01051fc0848535ff784809e9e2)
* [map/multimap](https://github.com/llvm/llvm-project/commit/edfe8525de1f7278f4754f2bffd47b13ec291a17)
* [set/multiset](https://github.com/llvm/llvm-project/commit/e20865c387e09ea0ebd5add15c762cd5271ff65f)
* [unordered_set/unordered_multiset](https://github.com/llvm/llvm-project/commit/296a80102a9b72c3eda80558fb78a3ed8849b341)
* [unordered_map/unordered_multimap](https://github.com/llvm/llvm-project/commit/dfcd4384cbcac0eeb7e5cbce350f875ba4da79d5)
* [function](https://github.com/llvm/llvm-project/commit/e1eabcdfad89f67ae575b0c86aa4a72d277378b4)
* [tuple](https://github.com/llvm/llvm-project/commit/1308011e1b5c5382281a63dd4191a1784f8d2295)
* [shared_ptr/weak_ptr](https://github.com/llvm/llvm-project/commit/83564056d4b186c9fcf016cdbb388755009f7b5a)

Additional notes:
* It was revision 2 of the paper that was voted into the Standard.
P0433R3 is a separate paper that is not part of the Standard.
* The paper also mandates removing several `make_*_searcher` functions
(e.g. `make_boyer_moore_searcher`) which are currently not implemented
(except in `experimental/`).
* The `__cpp_lib_deduction_guides` feature test macro from the paper was
accidentally omitted from the Standard.

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

show more ...


# b8608b87 28-Sep-2021 Mark de Wever <[email protected]>

[libc++] Use addressof in assignment operator.

Replace `&__rhs` with `_VSTD::addressof(__rhs)` to guard against ADL hijacking
of `operator&` in `operator=`. Thanks to @CaseyCarter for bringing it to

[libc++] Use addressof in assignment operator.

Replace `&__rhs` with `_VSTD::addressof(__rhs)` to guard against ADL hijacking
of `operator&` in `operator=`. Thanks to @CaseyCarter for bringing it to our
attention.

Similar issues with hijacking `operator&` still exist, they will be
addressed separately.

Reviewed By: #libc, Quuxplusone, ldionne

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

show more ...


# 469d18c0 31-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] Fix result-type and value_type computation in <valarray>.

The `operator[]` of `_UnaryOp` and `_BinaryOp` returns the result of
calling `__op_`, so its return type should be `__result_type`,

[libc++] Fix result-type and value_type computation in <valarray>.

The `operator[]` of `_UnaryOp` and `_BinaryOp` returns the result of
calling `__op_`, so its return type should be `__result_type`, not
e.g. `_A0::value_type`. However, `_UnaryOp::value_type` also should
never have been `_A0::value_type`; it needs to be the correct type
for the result of the unary op, e.g. `bool` when the op is `logical_not`.

This turns out to matter when multiple operators are nested, e.g.
`+(v == v)` needs to have a `value_type` of `bool`, not `int`,
even when `v` is of type `valarray<int>`.

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

show more ...


# d39f5c3c 29-May-2021 Arthur O'Dwyer <[email protected]>

[libc++] Avoid `result_type` and `unary/binary_function` in <valarray>.

Give each of the relevant functional operators a `__result_type`
instead, so that we can keep using those typedefs in <valarra

[libc++] Avoid `result_type` and `unary/binary_function` in <valarray>.

Give each of the relevant functional operators a `__result_type`
instead, so that we can keep using those typedefs in <valarray>
even when the public binder typedefs are removed in C++20.

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

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


# 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, llvmorg-12.0.0-rc4, 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
# 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 ...


# 644f68ed 02-Dec-2020 zoecarver <[email protected]>

[libc++] Add slice_array operator= valarray overload.

Add the slice_array::operator=(const std::valarray<T>& val_arr) overload.

Fixes https://llvm.org/PR40792.

Differential Revision: https://revie

[libc++] Add slice_array operator= valarray overload.

Add the slice_array::operator=(const std::valarray<T>& val_arr) overload.

Fixes https://llvm.org/PR40792.

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

show more ...


Revision tags: llvmorg-11.0.1-rc1
# 527a7fdf 24-Nov-2020 Bruce Mitchener <[email protected]>

[libc++] Replace several uses of 0 by nullptr

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


Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5
# 59f8ac3e 28-Sep-2020 Louis Dionne <[email protected]>

[libc++] Replace uses of __libcpp_allocate by std::allocator<>

Both are equivalent, however std::allocator can appear in constant
expressions and is higher level.


Revision tags: llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init
# f97936fa 13-Dec-2019 Eric Fiselier <[email protected]>

[libc++] Cleanup and enable multiple warnings.

Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-eval

[libc++] Cleanup and enable multiple warnings.

Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.

In future, all warnings disabled for the test suite should require
an attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.

show more ...


Revision tags: llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1
# de329354 25-Apr-2019 Richard Smith <[email protected]>

Remove incorrect explicit instantiation declarations for valarray

libc++ ABI v1 provides three valarray symbols as part of the shared library:

valarray<size_t>::valarray(size_t)
valarray<size_t>::~

Remove incorrect explicit instantiation declarations for valarray

libc++ ABI v1 provides three valarray symbols as part of the shared library:

valarray<size_t>::valarray(size_t)
valarray<size_t>::~valarray()
valarray<size_t>::resize(size_t, size_t)

The first two of these are intended to be removed in V2 of the ABI: they're
attributed _LIBCPP_HIDE_FROM_ABI_AFTER_V1, and it appears that the intention
is that these symbols from the library are not used even when building using
the V1 ABI. However, there are explicit instantiation declarations for all
three symbols in the header, which are not correct as we do not intend to find
an instantiation of these functions that is provided elsewhere.

(A recent change to clang to properly diagnose explicit instantiation
declarations of internal linkage functions -- required by [temp.explicit]p13 --
had to be rolled back because it diagnosed these explicit instantiations.)

Remove the explicit instantiation declarations, and remove the explicit
instantiation definitions for V2 of the libc++ ABI onwards.

llvm-svn: 359243

show more ...


# 06571975 02-Apr-2019 Eric Fiselier <[email protected]>

Fix a number of bugs in __val_expr's subset operator[].

The current definitions were entirely broken. They didn't call any
existing constructor and the forgot to friend the expression types they
wer

Fix a number of bugs in __val_expr's subset operator[].

The current definitions were entirely broken. They didn't call any
existing constructor and the forgot to friend the expression types they
were trying to construct.

llvm-svn: 357453

show more ...


123