summaryrefslogtreecommitdiffstats
path: root/libcxx/include/experimental
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] Strip trailing whitespace from libc++Louis Dionne2019-10-233-48/+48
|
* [libc++][NFC] Remove excess trailing newlines from most filesCasey Carter2019-10-231-1/+0
| | | | Testing git commit access.
* [libcxx] Do not implicitly #include assert.hDavid Zarzycki2019-09-261-1/+0
| | | | | | | | | Users should only get the assert() macros if they explicitly include them. Found after switching from the GNU C++ stdlib to the LLVM C++ stdlib. llvm-svn: 372963
* [libcxx] Slightly improved policy for handling experimental featuresLouis Dionne2019-06-119-161/+7
| | | | | | | | | | | | | | | | | | | | Summary: Following the discussion on the libcxx-dev mailing list (http://lists.llvm.org/pipermail/libcxx-dev/2019-May/000358.html), this implements the new policy for handling experimental features and their deprecation. We basically add a deprecation warning for std::experimental::filesystem, and we remove a bunch of <experimental/*> headers that were now empty. Reviewers: mclow.lists, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits, jfb Tags: #libc Differential Revision: https://reviews.llvm.org/D62428 llvm-svn: 363072
* Implement LWG 2960: nonesuch is insufficiently uselessMarshall Clow2019-04-301-5/+5
| | | | llvm-svn: 359526
* Fix visibility for coroutine types on WindowsEric Fiselier2019-04-171-3/+3
| | | | llvm-svn: 358551
* Revert "[coroutines] Add std::experimental::task<T> type"Brian Gesiak2019-03-263-510/+8
| | | | | | | | This revision is causing build and test failures, such as http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv8-linux/builds/648/steps/test.libcxx/logs/stdio, so I'll revert it. llvm-svn: 357023
* [coroutines] Add std::experimental::task<T> typeBrian Gesiak2019-03-263-8/+510
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Adds the coroutine `std::experimental::task<T>` type described in proposal P1056R0. See https://wg21.link/P1056R0. This implementation allows customization of the allocator used to allocate the coroutine frame by passing std::allocator_arg as the first argument, followed by the allocator to use. This supports co_awaiting the same task multiple times. The second and subsequent times it returns a reference to the already-computed value. This diff also adds some implementations of other utilities that have potential for standardization as helpers within the test/... area: - `sync_wait(awaitable)` - See P1171R0 - `manual_reset_event` Move the definition of the __aligned_allocation_size helper function from <experimental/memory_resource> to <experimental/__memory> so it can be more widely used without pulling in memory_resource. Outstanding work: - Use C++14 keywords directly rather than macro versions eg. use `noexcept` instead of `_NOEXCEPT`). - Add support for overaligned coroutine frames. This may need wording in the Coroutines TS to support passing the extra `std::align_val_t`. - Eliminate use of `if constexpr` if we want it to compile under C++14. Patch by @lewissbaker (Lewis Baker). llvm-svn: 357010
* [libc++] Remove visibility-related warnings with Clang 8Louis Dionne2019-02-271-6/+3
| | | | | | | The attributes were placed incorrectly -- they need to be after the "struct" keyword, not before. llvm-svn: 355006
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1927-108/+81
| | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-193-12/+9
| | | | | | | | | | | | | | | | | to reflect the new license. 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: 351636
* Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`. Eric Fiselier2019-01-162-7/+7
| | | | | | | | | | | | | | | | | | | | | 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
* Fix PR39749 - Headers containing just #error harm __has_include.Eric Fiselier2019-01-068-19/+99
| | | | | | | | | | | This patch changes <experimental/foo> to use #warning instead of is harmful to common feature detection idioms. We should also consider only emitting the warning when __DEPRECATED is defined, like we do in the <ext/foo> headers. Users may want to specify "-Werror=-W#warnings" while still ignoring the libc++ warnings. llvm-svn: 350485
* Revert "Move internal usages of `alignof`/`__alignof` to use ↵Eric Fiselier2018-11-281-3/+3
| | | | | | | | | | | `_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
* Move internal usages of `alignof`/`__alignof` to use `_LIBCPP_ALIGNOF`. Eric Fiselier2018-11-281-3/+3
| | | | | | | | | | | | | | | | | | | | | 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
* [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
* Re-apply "[libcxx] implement <simd> ABI for Clang/GCC vector extension, ↵Tim Shen2018-07-302-48/+340
| | | | | | | | constructors, copy_from and copy_to." ...with proper guarding #ifdefs for unsupported C++11. llvm-svn: 338318
* Revert "[libcxx] implement <simd> ABI for Clang/GCC vector extension, ↵Tim Shen2018-07-302-336/+48
| | | | | | | | constructors, copy_from and copy_to." This reverts commit r338309. llvm-svn: 338316
* [libcxx] implement <simd> ABI for Clang/GCC vector extension, constructors, ↵Tim Shen2018-07-302-48/+336
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | copy_from and copy_to. Summary: This patch adds a new macro _LIBCPP_HAS_NO_VECTOR_EXTENSION for detecting whether a vector extension (\_\_attribute\_\_((vector_size(num_bytes)))) is available. On the top of that, this patch implements the following API: * all constructors * operator[] * copy_from * copy_to It also defines simd_abi::native to use vector extension, if available. In GCC and Clang, certain values with vector extension are passed by registers, instead of memory. Based on D41148. Reviewers: mclow.lists, EricWF Subscribers: cfe-commits, MaskRay, lichray, sanjoy Differential Revision: https://reviews.llvm.org/D41376 llvm-svn: 338309
* Implement <filesystem>Eric Fiselier2018-07-272-2464/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the <filesystem> header and uses that to provide <experimental/filesystem>. Unlike other standard headers, the symbols needed for <filesystem> have not yet been placed in libc++.so. Instead they live in the new libc++fs.a library. Users of filesystem are required to link this library. (Also note that libc++experimental no longer contains the definition of <experimental/filesystem>, which now requires linking libc++fs). The reason for keeping <filesystem> out of the dylib for now is that it's still somewhat experimental, and the possibility of requiring an ABI breaking change is very real. In the future the symbols will likely be moved into the dylib, or the dylib will be made to link libc++fs automagically). Note that moving the symbols out of libc++experimental may break user builds until they update to -lc++fs. This should be OK, because the experimental library provides no stability guarantees. However, I plan on looking into ways we can force libc++experimental to automagically link libc++fs. In order to use a single implementation and set of tests for <filesystem>, it has been placed in a special `__fs` namespace. This namespace is inline in C++17 onward, but not before that. As such implementation is available in C++11 onward, but no filesystem namespace is present "directly", and as such name conflicts shouldn't occur in C++11 or C++14. llvm-svn: 338093
* [libc++] Use __int128_t to represent file_time_type.Eric Fiselier2018-07-251-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The ``file_time_type`` time point is used to represent the write times for files. Its job is to act as part of a C++ wrapper for less ideal system interfaces. The underlying filesystem uses the ``timespec`` struct for the same purpose. However, the initial implementation of ``file_time_type`` could not represent either the range or resolution of ``timespec``, making it unsuitable. Fixing this requires an implementation which uses more than 64 bits to store the time point. I primarily considered two solutions: Using ``__int128_t`` and using a arithmetic emulation of ``timespec``. Each has its pros and cons, and both come with more than one complication. However, after a lot of consideration, I decided on using `__int128_t`. This patch implements that change. Please see the [FileTimeType Design Document](http://libcxx.llvm.org/docs/DesignDocs/FileTimeType.html) for more information. Reviewers: mclow.lists, ldionne, joerg, arthur.j.odwyer, EricWF Reviewed By: EricWF Subscribers: christof, K-ballo, cfe-commits, BillyONeal Differential Revision: https://reviews.llvm.org/D49774 llvm-svn: 337960
* Make <experimental/filesystem> explicitly require C++11.Eric Fiselier2018-07-251-161/+165
| | | | | | | | | | | | | | Previously the <experimental/filesystem> didn't guard its contents in any dialect. However, the implementation implicitly requires at least C++11, and the tests have always been marked unsupported in C++03. This patch puts a header guard around the contents to avoid exposing them before C++11. Additionally, it replaces all of the usages of _NOEXCEPT or _LIBCPP_CONSTEXPR with the keyword directly, since we can expect the compiler to implement those by now. llvm-svn: 337884
* Ensure path::iterator and PathParser share the same enumeration values.Eric Fiselier2018-07-251-9/+18
| | | | | | | | | | | | To avoid exposing implementation details, path::iterator and PathParser both implicitly used the same set of values to represent the state, but they were defined twice. This could have lead to a mismatch occuring. This patch moves all of the parser state values into the filesystem header and changes PathParser to use those value to avoid this. llvm-svn: 337883
* Recommit "Use possibly cached directory entry values when performing ↵Eric Fiselier2018-07-231-2/+10
| | | | | | | | | | | | | recursive directory iteration." The initial patch didn't correctly handle systems when the dirent struct didn't provide the d_type member. Specifically it set the cache to the incorrect state, and claimed it was partially populated. The updated version of this change correctly handles setting up the cache when the file type is not known (aka file_type::none). llvm-svn: 337765
* Implement filesystem_error::what() and improve reporting.Eric Fiselier2018-07-231-25/+36
| | | | | | | | | | | This patch implements the `what()` for filesystem errors. The message includes the 'what_arg', any paths that were specified, and the error code message. Additionally this patch refactors how errors are created, making it easier to report them correctly. llvm-svn: 337664
* Fix two test failures in <experimental/filesystem>Eric Fiselier2018-07-201-0/+5
| | | | | | | | | | First, <experimental/filesystem> didn't correctly guard against min/max macros. This adds the proper push/pop macro guards. Second, an internal time helper had been renamed but the test for it hadn't been updated. This patch updates those tests. llvm-svn: 337520
* Use _LIBCPP_UNREACHABLE to convince GCC that non-void functions actually ↵Eric Fiselier2018-07-201-0/+8
| | | | | | always return llvm-svn: 337519
* [libc++] Implement Directory Entry Caching -- Sort of.Eric Fiselier2018-07-201-11/+382
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements directory_entry caching *almost* as specified in P0317r1. However, I explicitly chose to deviate from the standard as I'll explain below. The approach I decided to take is a fully caching one. When `refresh()` is called, the cache is populated by calls to `stat` and `lstat` as needed. During directory iteration the cache is only populated with the `file_type` as reported by `readdir`. The cache can be in the following states: * `_Empty`: There is nothing in the cache (likely due to an error) * `_IterSymlink`: Created by directory iteration when we walk onto a symlink only the symlink file type is known. * `_IterNonSymlink`: Created by directory iteration when we walk onto a non-symlink. Both the regular file type and symlink file type are known. * `_RefreshSymlink` and `_RefreshNonSymlink`: A full cache created by `refresh()`. This case includes dead symlinks. * `_RefreshSymlinkUnresolved`: A partial cache created by refresh when we fail to resolve the file pointed to by a symlink (likely due to permissions). Symlink attributes are cached, but attributes about the linked entity are not. As mentioned, this implementation purposefully deviates from the standard. According to some readings of the specification, and the Windows filesystem implementation, the constructors and modifiers which don't pass an `error_code` must throw when the `directory_entry` points to a entity which doesn't exist. or when attribute resolution fails for another reason. @BillyONeal has proposed a more reasonable set of requirements, where modifiers other than refresh ignore errors. This is the behavior libc++ currently implements, with the expectation some form of the new language will be accepted into the standard. Some additional semantics which differ from the Windows implementation: 1. `refresh` will not throw when the entry doesn't exist. In this case we can still meet the functions specification, so we don't treat it as an error. 2. We don't clear the path name when a constructor fails via refresh (this will hopefully be changed in the standard as well). It should be noted that libstdc++'s current implementation has the same behavior as libc++, except for point (2). If the changes to the specification don't get accepted, we'll be able to make the changes later. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html Reviewers: mclow.lists, gromer, ldionne, aaron.ballman Subscribers: BillyONeal, christof, cfe-commits Differential Revision: https://reviews.llvm.org/D49530 llvm-svn: 337516
* [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-112-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | _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
* [libc++] Declare noop_coroutine() with _LIBCPP_INLINE_VISIBILITYLouis Dionne2018-07-101-0/+1
| | | | | | | | | | | | | | | | | Summary: It was defined with the right visibility, but declared without any visibility. This function was left out of a prior revision that did the same to several functions in <compare> (r336665) because the compiler I used didn't support coroutines. This reinforces the need for automated checks -- there might still be several cases of this throughout the library. Reviewers: EricWF Subscribers: modocache, christof, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D49145 llvm-svn: 336709
* Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-052-7/+7
| | | | | | | | | | | | | | | _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-052-7/+7
| | | | | | | | | | | | | | | | | | | | 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
* Remove unused code from __functional_base. NFC.Eric Fiselier2018-06-061-2/+2
| | | | | | | | | | | | | | Patch from Arthur O'Dwyer. `__user_alloc_construct_impl` is used by <experimental/memory_resource>, but this `__user_alloc_construct` is never used. Also, `<experimental/memory_resource>` doesn't need a full definition of `std::tuple`; just the forward declaration in `<__tuple>` will suffice. Reviewed as https://reviews.llvm.org/D46806 llvm-svn: 334069
* LWG 2969 "polymorphic_allocator::construct() shouldn't pass resource()"Eric Fiselier2018-05-291-11/+11
| | | | | | | | | | | | | | | | | | | Patch from Arthur O'Dwyer. In the TS, `uses_allocator` construction for `pair` tried to use an allocator type of `memory_resource*`, which is incorrect because `memory_resource*` is not an allocator type. LWG 2969 fixed it to use `polymorphic_allocator` as the allocator type instead. https://wg21.link/lwg2969 (D47090 included this in `<memory_resource>`; at Eric's request, I've split this out into its own patch applied to the existing `<experimental/memory_resource>` instead.) Reviewed as https://reviews.llvm.org/D47109 llvm-svn: 333384
* Allow copy elision in path concatenationDavid Bolvansky2018-05-091-1/+3
| | | | | | | | | | | | | | | | | Summary: Just port of libstdc++'s fix to libc++ fs: https://github.com/gcc-mirror/gcc/commit/e6ac4004fe49d785c63bf87aec4b095b5ce1d19f Author of fix: Jonathan Wakely Reviewers: EricWF, mclow.lists Reviewed By: EricWF Subscribers: smeenai, christof, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D46593 llvm-svn: 331910
* Re-commit r330627 "[libcxx] implement <experimental/simd> declarations based ↵Tim Shen2018-04-232-0/+1297
| | | | | | | | | | | | on P0214R7." There are 3 changes: * Renamed genertor.pass.cpp to generator.pass.cpp * Removed nothing_to_do.pass.cpp * Mark GCC 4.9 as UNSUPPORTED for the test files that have negative narrowing conversion SFINAE test (see GCC PR63723). llvm-svn: 330655
* Revert "[libcxx] implement <experimental/simd> declarations based on P0214R7."Tim Shen2018-04-232-1297/+0
| | | | | | | | This reverts commit r330627. This causes several bots to freak out. llvm-svn: 330636
* [libcxx] implement <experimental/simd> declarations based on P0214R7.Tim Shen2018-04-232-0/+1297
| | | | | | | | | | | | | | | Summary: The patch includes all declarations, and also implements the following features: * ABI. * narrowing-conversion related SFIANE, including simd<> ctors and (static_)simd_cast. Reviewers: mclow.lists, EricWF Subscribers: lichray, sanjoy, MaskRay, cfe-commits Differential Revision: https://reviews.llvm.org/D41148 llvm-svn: 330627
* [coroutines] libcxx, noop_coroutine, make bots even more happyGor Nishanov2018-04-051-3/+3
| | | | llvm-svn: 329245
* [coroutines] Allow compilation under c++03Gor Nishanov2018-04-041-1/+1
| | | | llvm-svn: 329239
* [coroutines] Add noop_coroutine to <experimental/coroutine>Gor Nishanov2018-04-041-29/+68
| | | | | | | | | | | | | | A recent addition to Coroutines TS (https://wg21.link/p0913) adds a pre-defined coroutine noop_coroutine that does nothing. This patch implements require library types in <experimental/coroutine> Related clang and llvm patches: https://reviews.llvm.org/D45114 https://reviews.llvm.org/D45120 llvm-svn: 329237
* Implement P0430R2 - File system library on non-POSIX systems.Eric Fiselier2018-04-021-5/+14
| | | | | | | | | | | This patch implements P0430R2, who's largest change is adding the path::format enumeration for supporting path format conversions in path constructors. However, since libc++'s filesystem only really supports POSIX like systems, there are no real changes needed. This patch simply adds the format enum and then ignores it when it's passed to constructors. llvm-svn: 329031
* Implement filesystem NB comments, relative paths, and related issues.Eric Fiselier2018-04-021-46/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a fairly large patch that implements all of the filesystem NB comments and the relative paths changes (ex. adding weakly_canonical). These issues and papers are all interrelated so their implementation couldn't be split up nicely. This patch upgrades <experimental/filesystem> to match the C++17 spec and not the published experimental TS spec. Some of the changes in this patch are both API and ABI breaking, however libc++ makes no guarantee about stability for experimental implementations. The major changes in this patch are: * Implement NB comments for filesystem (P0492R2), including: * Implement `perm_options` enum as part of NB comments, and update the `permissions` function to match. * Implement changes to `remove_filename` and `replace_filename` * Implement changes to `path::stem()` and `path::extension()` which support splitting examples like `.profile`. * Change path iteration to return an empty path instead of '.' for trailing separators. * Change `operator/=` to handle absolute paths on the RHS. * Change `absolute` to no longer accept a current path argument. * Implement relative paths according to NB comments (P0219r1) * Combine `path.cpp` and `operations.cpp` since some path functions require access to the operations internals, and some fs operations require access to the path parser. llvm-svn: 329028
* Implement filesystem::perm_options specified in NB comments.Eric Fiselier2018-03-261-11/+53
| | | | | | | | | | The NB comments for filesystem changed permissions and added a new enum `perm_options` which control how the permissions are applied. This implements than NB resolution llvm-svn: 328476
* Fix dynarray test failures after changing __libcpp_allocate/deallocateEric Fiselier2018-03-221-7/+8
| | | | llvm-svn: 328182
* Implement LWG#2518 - Non-member swap for propagate_const should call member swapMarshall Clow2018-03-081-2/+1
| | | | llvm-svn: 327005
* While implementing P0777 - preventing unnecessary decay, I found some ↵Marshall Clow2018-02-121-4/+4
| | | | | | non-public uses of decay that could be replaced by __uncvref. NFC intented llvm-svn: 324895
OpenPOWER on IntegriCloud