Commit Graph

61 Commits

Author SHA1 Message Date
Corentin Jabot 48f8a7c4f2 [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
2022-02-24 19:58:08 -05:00
Nikolas Klauser 2e2f3158c6 [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
2022-02-16 04:12:22 +01:00
Arthur O'Dwyer fa6b9e4010 [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
2022-02-04 12:27:19 -05:00
Mark de Wever bd6e6846e7 [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
2022-01-04 19:50:59 +01:00
Louis Dionne eb8650a757 [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.
2021-11-17 16:30:52 -05:00
Konstantin Varlamov f9f97cae82 [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](af65856eec)
* [basic_string](6d9f750dec)
* [array](0ca8c0895c)
* [deque](dbb6f8a817)
* [forward_list](e076700b77)
* [list](4a227e582b)
* [vector](df8f754792)
* [queue/stack/priority_queue](5b8b8b5dce)
* [basic_regex](edd5e29cfe)
* [optional](f35b4bc395)
* [map/multimap](edfe8525de)
* [set/multiset](e20865c387)
* [unordered_set/unordered_multiset](296a80102a)
* [unordered_map/unordered_multimap](dfcd4384cb)
* [function](e1eabcdfad)
* [tuple](1308011e1b)
* [shared_ptr/weak_ptr](83564056d4)

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
2021-10-28 11:09:51 -07:00
Mark de Wever b8608b8723 [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
2021-10-07 18:10:47 +02:00
Arthur O'Dwyer 469d18c064 [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
2021-06-05 12:29:36 -04:00
Arthur O'Dwyer d39f5c3cb9 [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
2021-05-31 11:29:16 -04:00
Arthur O'Dwyer bfbd73f87d [libc++] Alphabetize and include-what-you-use. NFCI.
Differential Revision: https://reviews.llvm.org/D102781
2021-05-29 19:54:48 -04:00
Louis Dionne 4cd6ca102a [libc++] NFC: Normalize `#endif //` comment indentation 2021-04-20 12:03:32 -04:00
Arthur O'Dwyer be4c657b01 [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
2020-12-14 12:08:34 -05:00
zoecarver 644f68ed4d [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
2020-12-02 10:49:20 -08:00
Bruce Mitchener 527a7fdfbd [libc++] Replace several uses of 0 by nullptr
Differential Revision: https://reviews.llvm.org/D43159
2020-11-27 10:00:21 -05:00
Louis Dionne 59f8ac3eb4 [libc++] Replace uses of __libcpp_allocate by std::allocator<>
Both are equivalent, however std::allocator can appear in constant
expressions and is higher level.
2020-09-28 16:09:42 -04:00
Eric Fiselier f97936fabd [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.
2019-12-12 21:09:08 -05:00
Richard Smith de329354aa 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
2019-04-25 21:31:58 +00:00
Eric Fiselier 0657197588 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
2019-04-02 08:05:23 +00:00
Chandler Carruth 57b08b0944 Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648
2019-01-19 10:56:40 +00:00
Eric Fiselier d108bf85b0 Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`.
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See  llvm.org/PR39713

This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.

This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.

I think we should commit this change immediately, and decide what we want to do about the ABI afterwards. 

Reviewers: ldionne, EricWF

Reviewed By: ldionne, EricWF

Subscribers: jyknight, christof, libcxx-commits

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

llvm-svn: 351289
2019-01-16 01:51:12 +00:00
Eric Fiselier 9d25ada420 Revert "Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`. "
This reverts commit 087f065cb0c7463f521a62599884493aaee2ea12.

The tests were failing on 32 bit builds, and I don't have time
to clean them up right now. I'll recommit tomorrow with fixed tests.

llvm-svn: 347816
2018-11-28 22:24:19 +00:00
Eric Fiselier 8a486dac25 Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`.
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See  llvm.org/PR39713

This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.

This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.

I think we should commit this change immediately, and decide what we want to do about the ABI afterwards. 

Reviewers: ldionne, EricWF

Reviewed By: EricWF

Subscribers: christof, libcxx-commits

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

llvm-svn: 347787
2018-11-28 18:16:02 +00:00
Eric Fiselier 8622e866a6 fix incorrect placement of _LIBCPP_ALWAYS_INLINE in valarray
llvm-svn: 345289
2018-10-25 17:43:26 +00:00
Eric Fiselier f25b75b91b Implement sized deallocation for std::allocator and friends.
Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).

This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.

On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.

Reviewers: ldionne, mclow.lists

Reviewed By: ldionne

Subscribers: rsmith, ckennelly, libcxx-commits, christof

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

llvm-svn: 345281
2018-10-25 17:21:30 +00:00
Eric Christopher 9bbee38db3 Temporarily Revert "Implement sized deallocation for std::allocator and friends."
This is breaking the bots here (and related): http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-asan/builds/1428

This reverts commit r345214.

llvm-svn: 345239
2018-10-25 06:20:12 +00:00
Eric Fiselier 7e6448bb02 Implement sized deallocation for std::allocator and friends.
Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).

This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.

On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.

Reviewers: ldionne, mclow.lists

Reviewed By: ldionne

Subscribers: rsmith, ckennelly, libcxx-commits, christof

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

llvm-svn: 345214
2018-10-24 22:44:01 +00:00
Louis Dionne 7833b88ad8 [libcxx] Remove _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY
That macro has been defined to _LIBCPP_HIDE_FROM_ABI_AFTER_V1 for many
weeks now, so we're actually replacing uses of it for uses of
_LIBCPP_HIDE_FROM_ABI_AFTER_V1 directly.

This should not change or break anything since the two macros are
100% equivalent, unless somebody is (incorrectly!) relying on
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY being defined.

llvm-svn: 344641
2018-10-16 19:26:23 +00:00
Eric Fiselier f2918d1c24 Fix PR22634 - std::allocator doesn't respect over-aligned types.
This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-aligned
types.

__libcpp_allocate/deallocate now take an alignment parameter, and when
the specified alignment is greater than that supported by malloc/new,
the aligned version of operator new is called (assuming it's available).

When aligned new isn't available, the old behavior has been kept, and the
alignment parameter is ignored.

This patch depends on recent changes to __builtin_operator_new/delete which
allow them to be used to call any regular new/delete operator. By using
__builtin_operator_new/delete when possible, the new/delete erasure optimization
is maintained.

llvm-svn: 328180
2018-03-22 04:42:56 +00:00
Mikhail Maltsev 2b20304def [libcxx] Avoid spurious construction of valarray elements
Summary:
Currently libc++ implements some operations on valarray by using the
resize method. This method has a parameter with a default value.
Because of this, valarray may spuriously construct and destruct
objects of valarray's element type.
    
This patch fixes this issue and adds corresponding test cases.


Reviewers: EricWF, mclow.lists

Reviewed By: mclow.lists

Subscribers: rogfer01, cfe-commits

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

llvm-svn: 324596
2018-02-08 11:33:48 +00:00
Eric Fiselier a016efb1dc [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on Windows
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro`  to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.

Reviewers: mclow.lists, bcraig, compnerd, EricWF

Reviewed By: EricWF

Subscribers: cfe-commits, krytarowski

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

llvm-svn: 304357
2017-05-31 22:07:49 +00:00
Eric Fiselier 69154d6e07 Cleanup _LIBCPP_HAS_NO_<c++11-feature> macros in the numeric tests and headers
llvm-svn: 300632
2017-04-19 00:23:45 +00:00
Eric Fiselier cd71f447b7 [libc++] Tolerate presence of __deallocate macro
Summary:
On Windows the identifier `__deallocate` is defined as a macro by one of the Windows system headers. Previously libc++ worked around this by `#undef __deallocate` and generating a warning. However this causes the WIN32 version of `__threading_support` to always generate a warning on Windows. This is not OK.

This patch renames all usages of `__deallocate` internally as to not conflict with the macro.

Reviewers: mclow.lists, majnemer, rnk, rsmith, smeenai, compnerd

Subscribers: cfe-commits

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

llvm-svn: 291332
2017-01-07 03:01:24 +00:00
Eric Fiselier e2f2d1edef [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS
The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__type_visibility__)) with Clang. The only remaining difference
is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas
_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on
templates).

This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.

llvm-svn: 291035
2017-01-04 23:56:00 +00:00
Eric Fiselier 1fbaf535d6 Use _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY in valarray to support attribute((internal_linkage)).
The externally instantiated member functions must be declared using
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY, not _LIBCPP_INLINE_VISIBILITY, in
order to be properly exported when using __attribute__((internal_linkage)).

Otherwise the explicit instantiations will obviously have internal linkage and
will not be exported from the dylib.

llvm-svn: 281684
2016-09-16 00:13:55 +00:00
Eric Fiselier fd10d98ed0 Mark declarations of externally instantiated functions as inline so GCC doesn't complain.
llvm-svn: 255599
2015-12-15 01:41:41 +00:00
Evgeniy Stepanov 906c872db9 Cleanup: move visibility/linkage attributes to the first declaration.
This change moves visibility attributes from out-of-class method
definitions to in-class declaration. This is needed for a switch to
attribute((internal_linkage)) (see http://reviews.llvm.org/D13925)
which can only appear on the first declaration.

This change does not touch istream/ostream/streambuf. They are
handled separately in http://reviews.llvm.org/D14409.

llvm-svn: 252385
2015-11-07 01:22:13 +00:00
Saleem Abdulrasool 8e5ce33193 Handle function name conflicts in _LIBCPP_MSVCRT mode
Visual Studio's SAL extension uses a macro named __deallocate. This macro is
used pervasively, and gets included through various different ways. This
conflicts with the similarly named interfaces in libc++. Introduce a undef
header similar to __undef_min_max to handle this. This fixes a number of errors
due to the macro replacing the function name.

llvm-svn: 229162
2015-02-13 22:15:32 +00:00
Eric Fiselier 981a64c380 Add return statement to slice_array and mask_array assignment. Closes PR20614.
This patch just adds the required return statements to slice_array::operator=
and mask_array::operator=.

Tests were added to check that the return value is the same as the object assigned
to.

llvm-svn: 215414
2014-08-12 00:06:58 +00:00
Richard Smith ff0aff3caf Use __builtin_operator_new/__builtin_operator_delete when available. This
allows allocations and deallocations to be optimized out.

llvm-svn: 210211
2014-06-04 19:54:15 +00:00
Howard Hinnant f35fc7ad74 G M: Make valarray a little more forgiving to compilers not quite so gifted. This has no impact on clang.
llvm-svn: 190731
2013-09-13 23:27:42 +00:00
Howard Hinnant f0544c2086 Nico Rieck: this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.
llvm-svn: 188192
2013-08-12 18:38:34 +00:00
Howard Hinnant 6e41256f68 No functionality change at this time. I've split _LIBCPP_VISIBLE up into two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS. This is in preparation for taking advantage of clang's new __type_visibility__ attribute.
llvm-svn: 176593
2013-03-06 23:30:19 +00:00
Howard Hinnant cd47cbc7a4 Provide a way to disable use of extern templates in libc++. This is intended for the clients of libc++, not the libc++ build. The dylib should always contain the extern templates. To disable the client needs to put -D'_LIBCPP_EXTERN_TEMPLATE(...)=' on the command line.
llvm-svn: 167486
2012-11-06 21:08:48 +00:00
Howard Hinnant aeb85680fb Dimitry Andric: many visibility fixes. Howard: Much appreciated. Can you send me a patch to CREDITS.TXT?
llvm-svn: 163862
2012-09-14 00:39:16 +00:00
Howard Hinnant bf882037be noexcept applied to <valarray>.
llvm-svn: 160592
2012-07-21 00:51:28 +00:00
Douglas Gregor a336f5e645 Revert my _LIBCPP_INLINE_VISIBILITY changes, r157097 and r157107
llvm-svn: 157108
2012-05-19 07:14:17 +00:00
Douglas Gregor a1b6937dba valarray resize should not be _LIBCPP_INLINE_VISIBILITY
llvm-svn: 157107
2012-05-19 07:01:14 +00:00
Douglas Gregor 8f69b1af3d Move _LIBCPP_VISIBLE_INLINE from the out-of-line definitions of member
functions to the original declarations, so that Clang will actually
see them. Part of <rdar://problem/11489333>.

llvm-svn: 157097
2012-05-19 04:41:25 +00:00
Howard Hinnant c206366fd7 Quash a whole bunch of warnings
llvm-svn: 145624
2011-12-01 20:21:04 +00:00
Howard Hinnant c003db1fca Further macro protection by replacing _[A-Z] with _[A-Z]p
llvm-svn: 145410
2011-11-29 18:15:50 +00:00