summaryrefslogtreecommitdiffstats
path: root/libcxx/include/experimental/dynarray
Commit message (Collapse)AuthorAgeFilesLines
* [libcxx] Remove dynarrayLouis Dionne2018-11-281-305/+0
| | | | | | | | | | | | | | Summary: std::dynarray had been proposed for C++14, but it was pulled out from C++14 and there are no plans to standardize it anymore. Reviewers: mclow.lists, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits Differential Revision: https://reviews.llvm.org/D54801 llvm-svn: 347783
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-251-3/+3
| | | | | | | | | | | | | | | | | | | 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
* Revert "Fix use of __libcpp_deallocate in dynarray"Eric Christopher2018-10-251-1/+1
| | | | | | This reverts commit r345234 as it depended on the sized deallocation commit. llvm-svn: 345240
* Fix use of __libcpp_deallocate in dynarrayEric Fiselier2018-10-251-1/+1
| | | | llvm-svn: 345234
* [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Note that this commit had originally been applied in r336369 and then reverted in r336382 because of unforeseen problems. Both of these problems have now been fixed. Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, erikvanderpoel Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336866
* Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-051-1/+1
| | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY" This reverts commit r336369. The commit had two problems: 1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of _LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the dylib and the check-cxx-abilist failing. 2. The LLDB tests started failing because they undefine `_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and fix the tests before we can go forward with this change. llvm-svn: 336382
* [libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITYLouis Dionne2018-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Reviewers: EricWF Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336369
* Fix dynarray test failures after changing __libcpp_allocate/deallocateEric Fiselier2018-03-221-7/+8
| | | | llvm-svn: 328182
* [Libc++] Use #pragma push_macro/pop_macro to better handle min/max on WindowsEric Fiselier2017-05-311-0/+5
| | | | | | | | | | | | | | | | 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
* Add markup for libc++ dylib availabilityMehdi Amini2017-05-041-1/+1
| | | | | | | | | | | | | | | Libc++ is used as a system library on macOS and iOS (amongst others). In order for users to be able to compile a binary that is intended to be deployed to an older version of the platform, clang provides the availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_ that can be placed on declarations to describe the lifecycle of a symbol in the library. See docs/DesignDocs/AvailabilityMarkup.rst for more information. Differential Revision: https://reviews.llvm.org/D31739 llvm-svn: 302172
* [libc++] Tolerate presence of __deallocate macroEric Fiselier2017-01-071-8/+5
| | | | | | | | | | | | | | | 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
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-2/+2
| | | | | | | | | | | | | 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
* Add an _LIBCPP_NORETURN inline function named __throw_XXX for each exception ↵Marshall Clow2016-08-251-25/+6
| | | | | | type we define. They either construct and throw the exception, or abort() (if exceptions are disabled). Use these functions everywhere instead of assert()ing when exceptions are disabled. WARNING: This is a behavior change - but only with exceptions disabled. Reviewed as: https://reviews.llvm.org/D23855. llvm-svn: 279744
* Cleanup: move visibility/linkage attributes to the first declaration.Evgeniy Stepanov2016-04-221-5/+10
| | | | | | http://reviews.llvm.org/D15404 llvm-svn: 267093
* Fix initialzation order in dynarrayEric Fiselier2015-10-011-1/+1
| | | | llvm-svn: 248988
* Handle function name conflicts in _LIBCPP_MSVCRT modeSaleem Abdulrasool2015-02-131-0/+2
| | | | | | | | | | 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
* Update the synopsis and comments with the results of LWG #2255. No code to ↵Marshall Clow2014-07-231-13/+13
| | | | | | back it up at the moment; just comments llvm-svn: 213768
* Use __builtin_operator_new/__builtin_operator_delete when available. ThisRichard Smith2014-06-041-2/+2
| | | | | | allows allocations and deallocations to be optimized out. llvm-svn: 210211
* Move <dynarray> into include/experimental, and into the std::experimental ↵Marshall Clow2013-11-131-0/+314
namespace, since it's not part of C++14, but of an upcoming TS llvm-svn: 194614
OpenPOWER on IntegriCloud