summaryrefslogtreecommitdiffstats
path: root/libcxx/src
Commit message (Collapse)AuthorAgeFilesLines
...
* [libcxx] Don't use -fvisibility-global-new-delete-hidden when not defining themPetr Hosek2019-05-061-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | When builing the hermetic static library, the compiler switch -fvisibility-global-new-delete-hidden is necessary to get the new and delete operator definitions made correctly. However, when those definitions are not included in the library, then this switch does harm. With lld (though not all linkers) setting STV_HIDDEN on SHN_UNDEF symbols makes it an error to leave them undefined or defined via dynamic linking that should generate PLTs for -shared linking (lld makes this a hard error even without -z defs). Though leaving the symbols undefined would usually work in practice if the linker were to allow it (and the user didn't pass -z defs), this actually indicates a real problem that could bite some target configurations more subtly at runtime. For example, x86-32 ELF -fpic code generation uses hidden visibility on declarations in the caller's scope as a signal that the call will never be resolved to a PLT entry and so doesn't have to meet the special ABI requirements for PLT calls (setting %ebx). Since these functions might actually be resolved to PLT entries at link time (we don't know what the user is linking in when the hermetic library doesn't provide all the symbols itself), it's not safe for the compiler to treat their declarations at call sites as having hidden visibility. Differential Revision: https://reviews.llvm.org/D61571 llvm-svn: 360003
* [libc++][CMake] Link against libSystem on Apple platformsLouis Dionne2019-05-021-0/+4
| | | | | | | | Instead of manually linking against libm/librt/libpthread, we should be linking against libSystem on Apple platforms, and only that. libm and libpthread are symlinks to libSystem anyway. llvm-svn: 359808
* [WebAssembly] WASI support for libcxxDan Gohman2019-05-012-2/+4
| | | | | | | | | | | | | This adds explicit support for the WASI platform to libcxx. WASI libc uses some components from musl, however it's not fully compatible with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and customize for WASI libc specifically. Differential Revision: https://reviews.llvm.org/D61336 Reviewers: sbc100, ldionne llvm-svn: 359703
* [libcxx] Move CMake file to src, avoid using globsPetr Hosek2019-05-011-0/+472
| | | | | | | | | This addresses the longstanding FIXME and makes libc++ build more similar to other runtimes. Differential Revision: https://reviews.llvm.org/D61275 llvm-svn: 359656
* Fix r359229 which tried to fix r359159...Chandler Carruth2019-04-261-1/+1
| | | | | | | | When r359229 added noexcept to the declaration of `~mutex`, it didn't add it to the definition which caused -Wimplicit-exception-spec-mismatch to fire. This just adapts the definition to agree with the declaration. llvm-svn: 359275
* Remove incorrect explicit instantiation declarations for valarrayRichard Smith2019-04-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | 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
* [libc++] Remove redundant conditionals for Apple platformsLouis Dionne2019-04-233-8/+6
| | | | | | | | | | | | | | | | | | | Summary: In a bunch of places, we used to check whether LIBCXX_BUILDING_LIBCXXABI is defined OR we're building for an Apple platform. This used to be necessary in a time when Apple's build script did NOT define LIBCXX_BUILDING_LIBCXXABI. However this is not relevant anymore since Apple's build does define LIBCXX_BUILDING_LIBCXXABI. Reviewers: EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60842 llvm-svn: 358988
* [libc++][CMake] Remove unnecessary conditional for defining new handlersLouis Dionne2019-04-171-1/+1
| | | | | | | | | | | It turns out that whether the new handlers should be provided is orthogonal to whether new/delete are provided in libc++ or libc++abi. The reason why I initially added this conditional is because of an incorrect understanding of the path we're taking when building on Apple platforms. In fact, we always build libc++ on top of libc++abi on Apple platforms, so we take the branch for `LIBCXX_BUILDING_LIBCXXABI` there. llvm-svn: 358616
* [libc++] Use the no_destroy attribute to avoid destroying debug DB staticsLouis Dionne2019-04-171-2/+2
| | | | | | | | | | | | | | | | | Summary: Otherwise, we can run into problems when the program has static variables that need to use the debug database during their deinitialization, if the debug DB has already been deinitialized. Reviewers: EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60830 llvm-svn: 358602
* [libc++][NFC] Make size of allocation more self-documentingLouis Dionne2019-04-171-2/+2
| | | | llvm-svn: 358588
* [libc++] Remove old workaround for builditLouis Dionne2019-04-161-6/+2
| | | | | | | | | | | | | | | | | | | | Summary: I'm not sure what the problem was at the time, however I don't think this is necessary since buildit doesn't exist anymore. Instead of the workaround, the correct thing to do is to leave out the get_new_handler/set_new_handler definitions from libc++ when we're getting them from libc++abi. Reviewers: EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D60717 llvm-svn: 358518
* Fix typo that I introduced in r357413. Thanks to ensadc@mailnesia.com for ↵Marshall Clow2019-04-021-1/+2
| | | | | | the catch. llvm-svn: 357474
* Fix PR#41323 'Race condition in steady_clock::now for _LIBCPP_WIN32API'. ↵Marshall Clow2019-04-011-6/+15
| | | | | | thanks to Ivan Afanasyev for the report. llvm-svn: 357413
* [libc++] Fix return value of snprintf_l() on Windows when buffer is too smallThomas Anderson2019-03-261-4/+5
| | | | | | | | | | | | | | | | | When the output buffer is too small to contain the output, `vsnprintf()` fills the buffer and returns the number of characters that __would have__ been written if the buffer was sufficiently large. `_vnsprintf_s()` on the other hand fills the buffer and returns -1 when this happens. We want the former behavior, but we also want to be able to pass in a locale to prevent having to call `setlocale()`. `__stdio_common_vsprintf()` is the only function general enough to get the behavior we want. Differential Revision: https://reviews.llvm.org/D59727 llvm-svn: 357024
* [NFC][libc++] Reindent #ifdefsLouis Dionne2019-03-211-12/+12
| | | | | | | | I don't understand why we don't always do that. We do it for normal `if`s in the code, but not for preprocessor `if`s? It's a lot more readable when indented properly. llvm-svn: 356693
* libc++/win: Make once_flag have the same size as a pointer.Nico Weber2019-03-201-8/+8
| | | | | | | | | | | | | | | | | | | | | | `unsigned long` is 32-bit on 32-bit systems and 64-bit on 64-bit systems on LP64 systems -- which most Unix systems are, but Windows isn't. Windows is LLP64, which means unsigned long is 32-bit even on 64-bit systems. pplwin.h contains static_assert(alignof(void *) == alignof(::std::once_flag), ...) which fails due to this problem. Instead of unsigned long, use uintptr_t, which consistently is 32-bit on 32-bit systems and 64-bit on 64-bit systems. No functional change except on 64-bit Windows. Differential Revision: https://reviews.llvm.org/D59607 llvm-svn: 356624
* [libc++] Speed up certain locale functions on WindowsThomas Anderson2019-03-191-0/+6
| | | | | | | | | | | The issue is that __libcpp_locale_guard makes some slow calls to setlocale(). This change avoids using __libcpp_locale_guard in snprintf_l(). Fixes https://bugs.llvm.org/show_bug.cgi?id=41131 Differential Revision: https://reviews.llvm.org/D59525 llvm-svn: 356512
* Remove exception throwing debug mode handler support.Eric Fiselier2019-03-181-50/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The reason libc++ implemented a throwing debug mode handler was for ease of testing. Specifically, I thought that if a debug violation aborted, we could only test one violation per file. This made it impossible to test debug mode. Which throwing behavior we could test more! However, the throwing approach didn't work either, since there are debug violations underneath noexcept functions. This lead to the introduction of `_NOEXCEPT_DEBUG`, which was only noexcept when debug mode was off. Having thought more and having grown wiser, `_NOEXCEPT_DEBUG` was a horrible decision. It was viral, it didn't cover all the cases it needed to, and it was observable to the user -- at worst changing the behavior of their program. This patch removes the throwing debug handler, and rewrites the debug tests using 'fork-ing' style death tests. Reviewers: mclow.lists, ldionne, thomasanderson Reviewed By: ldionne Subscribers: christof, arphaman, libcxx-commits, #libc Differential Revision: https://reviews.llvm.org/D59166 llvm-svn: 356417
* LWG 2843 "Unclear behavior of std::pmr::memory_resource::do_allocate()"Eric Fiselier2019-03-091-10/+14
| | | | | | | | | | | | | | | | | | | | Patch by Arthur O'Dwyer. Reviewed as https://reviews.llvm.org/D47344 new_delete_resource().allocate(n, a) has basically two permissible results: * Return an appropriately sized and aligned block. * Throw bad_alloc. Before this patch, libc++'s new_delete_resource would do a third and impermissible thing, which was to return an appropriately sized but inappropriately under-aligned block. This is now fixed. (This came up while I was stress-testing unsynchronized_pool_resource on my MacBook. If we can't trust the default resource to return appropriately aligned blocks, pretty much everything breaks. For similar reasons, I would strongly support just patching __libcpp_allocate directly, but I don't care to die on that hill, so I made this patch as a <memory_resource>-specific workaround.) llvm-svn: 355763
* Fix ABI compatibility of `<stdexcept>` with VCRuntime.Eric Fiselier2019-03-063-81/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, libc++'s `<stdexcept>` doesn't play nice with `vcruntime`. Specifically: * `logic_error` and `runtime_error` have a different layout. * libc++'s `logic_error` and `runtime_error` override `what()` but `vcruntime` does not. * `vcruntime` uses weak vtables for `<stdexcept>` types. * libc++'s `<stdexcept>` constructors and assignment operators may have different manglings than `vcruntimes`. This patch makes libc++'s declarations in `<stdexcept>` match those provided by MSVC's STL as closely as possible. If MSVC doesn't declare a special member, then neither do we. This ensures that the implicit definitions have the same linkage, visibility, triviality, and noexcept-ness. Reviewers: thomasanderson, ldionne, smeenai Reviewed By: thomasanderson Subscribers: jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D58945 llvm-svn: 355546
* Fix -fsanitize=vptr badness in <__debug>Eric Fiselier2019-03-051-9/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a lifetime bug when inserting a new container into the debug database. It is diagnosed by UBSAN when debug mode is enabled. This patch corrects how nodes are constructed during insertion. The fix requires unconditionally breaking the debug mode ABI. Users should not expect ABI stability from debug mode. Reviewers: ldionne, serge-sans-paille, EricWF Reviewed By: EricWF Subscribers: mclow.lists, christof, libcxx-commits Tags: #libc Differential Revision: https://reviews.llvm.org/D58011 llvm-svn: 355367
* Make VCRuntime ABI configuration a first-class option.Eric Fiselier2019-03-054-8/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows we currently provide two separate ABI configurations. One which defers to `vcruntime` to provide the C++ runtime and another which doesn't. Using `vcruntime` allows interoperability which programs compiled against the MSVC STL, and should be preferred whenever possible. When deferring to `vcruntime` much of the ABI we provide changes. Including the layout of `<stdexcept>` types, their vtables, and how the linkage of their members. This patch introduces the `_LIBCPP_ABI_VCRUNTIME` macro to denote this configuration. It also cleans up the existing configuration for using `vcruntime`. This cleanup lays the groundwork for fixing a number of ABI and interoperability bugs in `<stdexcept>`. Reviewers: thomasanderson, ldionne, smeenai Reviewed By: smeenai Subscribers: jdoerfert, libcxx-commits, #libc Differential Revision: https://reviews.llvm.org/D58942 llvm-svn: 355366
* [libc++] Avoid UB in the no-exceptions mode in a few placesLouis Dionne2019-02-123-38/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: A few places in the library seem to behave unexpectedly when the library is compiled or used with exceptions disabled. For example, not throwing an exception when a pointer is NULL can lead us to dereference the pointer later on, which is UB. This patch fixes such occurences. It's hard to tell whether there are other places where the no-exceptions mode misbehaves like this, because the replacement for throwing an exception does not always seem to be abort()ing, but at least this patch will improve the situation somewhat. See http://lists.llvm.org/pipermail/libcxx-dev/2019-January/000172.html Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D57761 llvm-svn: 353850
* Handle cases where the dirent::d_type macros aren't definedEric Fiselier2019-02-011-0/+3
| | | | llvm-svn: 352942
* [libc++] Explicitly initialize std::nothrowThomas Anderson2019-01-301-1/+1
| | | | | | | | | | | | | When building on Windows without libc++abi, this change fixes a build error of the form: src/new.cpp(38,17): error: chosen constructor is explicit in copy-initialization const nothrow_t nothrow = {}; include/vcruntime_new.h(53,22): note: explicit constructor declared here explicit nothrow_t() = default; Differential Revision: https://reviews.llvm.org/D57351 llvm-svn: 352648
* [libc++] Don't define exception destructors when using vcruntimeThomas Anderson2019-01-301-15/+8
| | | | | | | | | | | | | Exception destructors are provided by vcruntime. Fixes link errors like: lld-link: error: duplicate symbol: "public: virtual __cdecl std::invalid_argument::~invalid_argument(void)" (??1invalid_argument@std@@UEAA@XZ) in stdexcept.obj and in libcpmt.lib(xthrow.obj) lld-link: error: duplicate symbol: "public: virtual __cdecl std::length_error::~length_error(void)" (??1length_error@std@@UEAA@XZ) in stdexcept.obj and in libcpmt.lib(xthrow.obj) lld-link: error: duplicate symbol: "public: virtual __cdecl std::out_of_range::~out_of_range(void)" (??1out_of_range@std@@UEAA@XZ) in stdexcept.obj and in libcpmt.lib(xthrow.obj) lld-link: error: duplicate symbol: "public: virtual __cdecl std::overflow_error::~overflow_error(void)" (??1overflow_error@std@@UEAA@XZ) in stdexcept.obj and in libcpmt.lib(xthrow.obj) Differential Revision: https://reviews.llvm.org/D57425 llvm-svn: 352646
* Commit D11348: 'Win32 support: wcsnrtombs and mbsnrtowcs don't handle null ↵Marshall Clow2019-01-231-0/+10
| | | | | | output buffers correctly' which has been hanging around for a long time llvm-svn: 351971
* Update more file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1954-216/+162
| | | | | | | | | | | | | | | | | | 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
* [hurd] Fix unconditional use of PATH_MAXEric Fiselier2019-01-171-6/+25
| | | | | | | | | | | Patch by Samuel Thibault The GNU/Hurd system does not define an arbitrary PATH_MAX limitation, the POSIX 2001 realpath extension can be used instead, and the size of symlinks can be determined. Reviewed as https://reviews.llvm.org/D54677 llvm-svn: 351414
* Fix size_t/off_t mixup in std::filesystem.Dan Albert2019-01-151-1/+2
| | | | | | | | | | | | | | Summary: ftruncate takes an off_t, not a size_t. Reviewers: EricWF, mclow.lists Reviewed By: EricWF Subscribers: christof, ldionne, libcxx-commits Differential Revision: https://reviews.llvm.org/D56578 llvm-svn: 351226
* Implement LWG 3096: path::lexically_relative is confused by trailing slashesEric Fiselier2018-12-211-3/+6
| | | | | | path("/dir/").lexically_relative("/dir"); now returns "." instead of "" llvm-svn: 349885
* Implement LWG 2936: Path comparison is defined in terms of the generic formatEric Fiselier2018-12-211-13/+84
| | | | | | | | | This patch implements path::compare according to the current spec. The only observable change is the ordering of "/foo" and "foo", which orders the two paths based on having or not having a root directory (instead of lexically comparing "/" to "foo"). llvm-svn: 349881
* [libcxx] Remove bad_array_lengthLouis Dionne2018-11-294-50/+0
| | | | | | | | | | | | | | | | Summary: std::bad_array_length was added by n3467, but this never made it into C++. This commit removes the definition of std::bad_array_length from the headers AND from the shared library. See the comments in the ABI changelog for details about the ABI implications of this change. Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF Subscribers: christof, jkorous, libcxx-commits Differential Revision: https://reviews.llvm.org/D54804 llvm-svn: 347903
* Add basic_string::__resize_default_init (from P1072)Eric Fiselier2018-11-261-12/+19
| | | | | | | | | | | This patch adds an implementation of __resize_default_init as described in P1072R2. Additionally, it uses it in filesystem to demonstrate its intended utility. Once P1072 lands, or if it changes it's interface, I will adjust the internal libc++ implementation to match. llvm-svn: 347589
* [libcxx] GNU/Hurd uses BSD-based interfaces, but does not (and won't) ↵Louis Dionne2018-11-131-2/+2
| | | | | | | | | | provide <sys/sysctl.h> Reviewed as https://reviews.llvm.org/D54338. Thanks to sthibaul for the patch. llvm-svn: 346763
* Make libc++'s versioning namespace customizableEric Fiselier2018-10-301-9/+9
| | | | | | | | | | | | | | | | | Summary: This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`. This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues. Reviewers: mclow.lists, ldionne Reviewed By: ldionne Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits Differential Revision: https://reviews.llvm.org/D53879 llvm-svn: 345657
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-251-2/+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
* [libc++] Make sure we can build libc++ with -fvisibility=hiddenLouis Dionne2018-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When building with -fvisibility=hidden, some symbols do not get exported from libc++.dylib. This means that some entities are not explicitly given default visibility in the source code, and that we rely on the fact -fvisibility=default is the default. This commit explicitly gives default visibility to those symbols to avoid being dependent on the command line flags used. The commit also remove symbols from the dylib -- those symbols do not actually need to be exported from the dylib and this should not be an ABI break. Finally, in the future, we may want to mark the whole std:: namespace as having hidden visibility (to switch from opt-out to opt-in), in which case the changes done in this commit will be required. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, libcxx-commits Differential Revision: https://reviews.llvm.org/D52662 llvm-svn: 345260
* Temporarily Revert "Implement sized deallocation for std::allocator and ↵Eric Christopher2018-10-251-2/+2
| | | | | | | | | | 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
* Implement sized deallocation for std::allocator and friends.Eric Fiselier2018-10-241-2/+2
| | | | | | | | | | | | | | | | | | | 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
* Distinguish between library and language support for aligned allocation.Eric Fiselier2018-10-111-3/+3
| | | | | | | | | | | | | | | | | | | | There are two cases: 1. The library has all it needs to provide align_val_t and the new/delete overloads needed to support aligned allocation. 2. The compiler has actually turned the language feature on. There are times where libc++ needs to distinguish between the two. This patch adds the additional macro _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1) does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever _LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the compiler has not enabled the language feature. Additionally this patch cleans up a number of other macros related to detection of aligned allocation machinery. llvm-svn: 344207
* Remove redundant null pointer check in operator deleteFangrui Song2018-10-011-5/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: C89 4.10.3.2 The free function C99 7.20.3.2 The free function C11 7.22.3.3 The free function If ptr is a null pointer, no action shall occur. _aligned_free on MSDN: If memblock is a NULL pointer, this function simply performs no actions. Reviewers: EricWF, mclow.lists, khng300, hotpxl Reviewed By: mclow.lists, khng300, hotpxl Subscribers: lichray, llvm-commits, hotpxl, khng300, christof, ldionne, cfe-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D52401 llvm-svn: 343503
* [cxx2a] Fix warning triggered by r343285Vitaly Buka2018-09-291-1/+0
| | | | llvm-svn: 343369
* Revert r342936 "Remove redundant null pointer check in operator delete"Louis Dionne2018-09-251-3/+5
| | | | | | | | A review for the change was opened in https://reviews.llvm.org/D52401 but the change was committed before being approved by any of the code owners for libc++. llvm-svn: 342938
* Remove redundant null pointer check in operator deleteFangrui Song2018-09-251-5/+3
| | | | | | | | | | | | | | | | | | | | C89 4.10.3.2 The free function C99 7.20.3.2 The free function C11 7.22.3.3 The free function If ptr is a null pointer, no action shall occur. _aligned_free on MSDN: If memblock is a NULL pointer, this function simply performs no actions. Reviewers: EricWF, mclow.lists Subscribers: christof, ldionne, cfe-commits, libcxx-commits Differential Revision: https://reviews.llvm.org/D52401 llvm-svn: 342936
* [libc++] Remove race condition in std::asyncLouis Dionne2018-08-241-4/+1
| | | | | | | | | | | | | | | | | Summary: The state associated to the future was set in one thread (with synchronization) but read in another thread without synchronization, which led to a data race. https://bugs.llvm.org/show_bug.cgi?id=38181 rdar://problem/42548261 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51170 llvm-svn: 340608
* [libc++][C++17] Elementary string conversions for integral typesZhihao Yuan2018-08-011-0/+233
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Major QoI considerations: - The facility is backported to C++14, same as libstdc++. - Efforts have been made to minimize the header dependencies. - The design is friendly to the uses of MSVC intrinsics (`__emulu`, `_umul128`, `_BitScanForward`, `_BitScanForward64`) but not implemented; future contributions are welcome. Thanks to Milo Yip for contributing the implementation of `__u64toa` and `__u32toa`. References: https://wg21.link/p0067r5 https://wg21.link/p0682r1 Reviewers: mclow.lists, EricWF Reviewed By: mclow.lists Subscribers: ldionne, Quuxplusone, christof, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D41458 llvm-svn: 338479
* [libc++] Remove _LIBCPP_BUILDING_XXX macros, which are redundant since ↵Louis Dionne2018-08-017-8/+0
| | | | | | | | | | | | | | _LIBCPP_BUILDING_LIBRARY Summary: As suggested by Marshall in https://reviews.llvm.org/D49914 Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50008 llvm-svn: 338475
* Code cleanup - change naked 'throw' expressions to call helpre function ↵Marshall Clow2018-07-301-33/+11
| | | | | | '__throw_future_error'. The behavior change is that if you build libc++ with exceptions disabled, and then use that in a program that sets the value of the future twice (for example), it will now abort instead of behaving unpredictably. llvm-svn: 338332
* Implement <filesystem>Eric Fiselier2018-07-274-516/+485
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud