summaryrefslogtreecommitdiffstats
path: root/libcxx/lib
Commit message (Collapse)AuthorAgeFilesLines
* [libc++] Fix build failures after merging <charconv>Zhihao Yuan2018-08-011-0/+2
| | | | | | | | | | | | | | Summary: - fix a stupid unit test typo - add <charconv> symbols to Linux abilist Reviewers: EricWF Subscribers: christof, ldionne, cfe-commits Differential Revision: https://reviews.llvm.org/D50130 llvm-svn: 338486
* Add libc++fs to the test deps, and not to the target 'cxx'.Eric Fiselier2018-07-271-7/+3
| | | | llvm-svn: 338096
* Attempt to unbreak *all the bots*Eric Fiselier2018-07-271-4/+6
| | | | | | | | The bots were failing to build the cxx_filesystem target, so the tests were failing. Though this does lead me to wonder how it was ever working with c++experimental. llvm-svn: 338095
* Implement <filesystem>Eric Fiselier2018-07-271-5/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [CMake] Option to control whether shared/static library is installedPetr Hosek2018-07-241-7/+10
| | | | | | | | | | | | | Currently it's only possible to control whether shared or static library build of libc++, libc++abi and libunwind is enabled or disabled and whether to install everything we've built or not. However, it'd be useful to have more fine grained control, e.g. when static libraries are merged together into libc++.a we don't need to install libc++abi.a and libunwind.a. This change adds this option. Differential Revision: https://reviews.llvm.org/D49573 llvm-svn: 337867
* Reland "[CMake] Support statically linking dependencies only to shared or ↵Petr Hosek2018-07-241-3/+3
| | | | | | | | static library" This is a reland of commit r337668. llvm-svn: 337814
* Revert "[CMake] Support statically linking dependencies only to shared or ↵Petr Hosek2018-07-231-3/+3
| | | | | | | | static library" This reverts commit r337668: broke the cxxabi build when using Make. llvm-svn: 337670
* [CMake] Support statically linking dependencies only to shared or static libraryPetr Hosek2018-07-231-3/+3
| | | | | | | | | | | | | | Currently it's possible to select whether to statically link unwinder or the C++ ABI library, but this option applies to both the shared and static library. However, in some scenarios it may be desirable to only statically link unwinder and C++ ABI library into static C++ library since for shared C++ library we can rely on dynamic linking and linker scripts. This change enables selectively enabling or disabling statically linking only to shared or static library. Differential Revision: https://reviews.llvm.org/D49502 llvm-svn: 337668
* [libc++] Allow running ABI list tests with different ABI versionsLouis Dionne2018-07-194-17/+2425
| | | | | | | | | | | | | | | Summary: Currently, the ABI list test only works for ABI version 1. This commit allows running the ABI list test with ABI version 2. It also adds an ABI list file for ABI v2 on Mac OS X. Reviewers: EricWF Subscribers: mgorny, christof, dexonsmith, llvm-commits, mclow.lists Differential Revision: https://reviews.llvm.org/D49509 llvm-svn: 337477
* [CMake] Rename cxx_headers back to cxx-headers.Ahmed Bougacha2018-06-281-1/+1
| | | | | | | | | | | | | | r334477 renamed the cxx-headers target to cxx_headers, but various pieces sort-of expect the target names to match the component (e.g., LLVM_DISTRIBUTION_COMPONENTS in the various bootstrap caches, which, via some magic foreign to me, seems to expect cxx-headers, install-cxx-headers, and install-cxx-headers-stripped to exist.) Revert back to cxx-headers. Differential Revision: https://reviews.llvm.org/D48701 llvm-svn: 335899
* [CMake] Use common variable for all header targets NFCPetr Hosek2018-06-121-4/+3
| | | | | | This simplifies the handling of header targets. llvm-svn: 334477
* [CMake] Add a missing target dependency on C++ ABI headersPetr Hosek2018-06-121-1/+1
| | | | | | | This resolves the breakage introduced in r334468 which results in build error when using CMake Makefile generator. llvm-svn: 334470
* Reland "Use custom command and target to install libc++ headers"Petr Hosek2018-06-121-1/+5
| | | | | | | | | | | | | | | | | | | Using file(COPY FILE...) has several downsides. Since the file command is only executed at configuration time, any changes to headers made after the initial CMake execution are ignored. This can lead to subtle errors since the just built Clang will be using stale libc++ headers. Furthermore, since the headers are copied prior to executing the build system, this may hide missing dependencies on libc++ from other LLVM components. This changes replaces the use of file(COPY FILE...) command with a custom command and target which addresses all aforementioned issues and matches the implementation already used by other LLVM components that also install headers like Clang builtin headers. Differential Revision: https://reviews.llvm.org/D44773 llvm-svn: 334468
* Update ABI lists after change in r333467.Eric Fiselier2018-05-298-1885/+10425
| | | | | | | | r333467 updated the symbols exported by libc++.so/dylib by changing the ODR usage of __uncaught_exception/__uncaught_exceptions. This should not be a breaking change. llvm-svn: 333481
* Revert "[CMake] Use custom command and target to install libc++ headers"Petr Hosek2018-04-091-2/+1
| | | | | | This reverts commit r329544 which is failing on libcxx standalone bots. llvm-svn: 329545
* [CMake] Use custom command and target to install libc++ headersPetr Hosek2018-04-091-1/+2
| | | | | | | | | | | | | | | | | | | Using file(COPY FILE...) has several downsides. Since the file command is only executed at configuration time, any changes to headers made after the initial CMake execution are ignored. This can lead to subtle errors since the just built Clang will be using stale libc++ headers. Furthermore, since the headers are copied prior to executing the build system, this may hide missing dependencies on libc++ from other LLVM components. This changes replaces the use of file(COPY FILE...) command with a custom command and target which addresses all aforementioned issues and matches the implementation already used by other LLVM components that also install headers like Clang builtin headers. Differential Revision: https://reviews.llvm.org/D44773 llvm-svn: 329544
* [CMake] Copy the generated __config header into build directoryPetr Hosek2018-03-101-1/+1
| | | | | | | | | | | | | | When the generated __config file is being used, it is currently only copied during installation process. However, that means that the file that gets copied into LLVM build directory is the vanilla __config file, and any parts of the build that depend on the just built toolchain like sanitizers will get that instead of the generated version. To avoid this issue, we need to copy the generated header into the LLVM build directory as well. Differential Revision: https://reviews.llvm.org/D43797 llvm-svn: 327194
* LLVM_FOUND isn't always set, so just test if llvm_setup_rpath() isDon Hinton2018-01-271-1/+1
| | | | | | available instead. llvm-svn: 323599
* Reland: [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.Don Hinton2018-01-261-0/+3
| | | | | | | | | Clang and llvm already use llvm_setup_rpath(), so this change will help standarize rpath usage across all projects. Differential Revision: https://reviews.llvm.org/D42459 llvm-svn: 323492
* Revert [libcxx] r323453 - [cmake] [libcxx] Call llvm_setup_rpath() when ↵Don Hinton2018-01-251-1/+0
| | | | | | | | | | adding shared libraries. Shoaib Meenai pointed out this will break standalone builds when built without llvm. Differential Revision: https://reviews.llvm.org/D42459 llvm-svn: 323459
* [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.Don Hinton2018-01-251-0/+1
| | | | | | | | | Clang and llvm already use llvm_setup_rpath(), so this change will help standarize rpath usage across all projects. Differential Revision: https://reviews.llvm.org/D42459 llvm-svn: 323453
* [libc++] Create install-stripped targetsShoaib Meenai2017-12-061-0/+8
| | | | | | | | | | | | LLVM is gaining install-*-stripped targets to perform stripped installs, and in order for this to be useful for install-distribution, all potential distribution components should have stripped installation targets. LLVM has a function to create these install targets, but since we can't use LLVM CMake functions in libc++, let's do it manually. Differential Revision: https://reviews.llvm.org/D40680 llvm-svn: 319959
* Update changelog revisionEric Fiselier2017-09-171-1/+1
| | | | llvm-svn: 313501
* ABI: Fix for undefined "___cxa_deleted_virtual" symbol in MacOSXEric Fiselier2017-09-175-0/+15
| | | | | | | | | | | | | | | | | | | | | | Patch from Eddie Elizondo. Reviewed as D37830 (https://reviews.llvm.org/D37830). On MacOSX the following program: struct S { virtual void f() = delete; }; int main() { new S; } Fails with the following error: Undefined symbols for architecture x86_64: "___cxa_deleted_virtual" This adds a fix to export the needed symbols. Test: > lit -sv test/libcxx/language.support/cxa_deleted_virtual.pass.cpp > Testing Time: 0.21s > Expected Passes : 1 llvm-svn: 313500
* Use CMAKE_AR instead of the system default 'ar' for merging static librariesMartin Storsjo2017-09-131-0/+1
| | | | | | | | | | | | | | | Using the system default 'ar' might not be the right choice when cross compiling. Don't prepend the ar options by a dash, not all ar implementations support that (llvm-ar doesn't). Also pass the 's' option when creating the merged library, to create an index. Differential Revision: https://reviews.llvm.org/D37134 llvm-svn: 313122
* Add MINGW_LIBRARIES to the linker flagsMartin Storsjo2017-09-041-0/+1
| | | | | | | | | | This is essential when building with -nodefaultlibs. This is similar to what already is done in libcxxabi in SVN r302760. Differential revision: https://reviews.llvm.org/D37207 llvm-svn: 312498
* [CMake] Use MATCHES for regular expression.Leo Li2017-07-181-1/+1
| | | | | | | | Subscribers: mgorny Differential Revision: https://reviews.llvm.org/D35514 llvm-svn: 308347
* [libcxx][CMake] Add install path variable to allow overriding the destinationPetr Hosek2017-07-111-3/+3
| | | | | | | | | This is going to be used by the runtime build in the multi-target setup to allow using different install prefix for each target. Differential Revision: https://reviews.llvm.org/D33762 llvm-svn: 307615
* Move external instantiation for __vector_base_common to vector.cppEric Fiselier2017-06-151-0/+1
| | | | | | | | Previously the explicit instantiation for this was in locale.cpp, but that didn't make much sense. This patch creates a new vector.cpp source file to contain the explicit instantiation. llvm-svn: 305442
* libcxx: fix bootstrapping for mingw-w64Martell Malone2017-05-251-5/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D33388 llvm-svn: 303928
* [libc++] Implement exception_ptr on WindowsEric Fiselier2017-05-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements exception_ptr on Windows using the `__ExceptionPtrFoo` functions provided by MSVC. The `__ExceptionPtrFoo` functions are defined inside the C++ standard library, `msvcprt`, which is unfortunate because it requires libc++ to link to the MSVC STL. However this doesn't seem to cause any immediate problems. However to be safe I kept all usages within the libc++ dylib so that user programs wouldn't have to link to MSVCPRT as well. Note there are still 2 outstanding exception_ptr/nested_exception test failures. * `current_exception.pass.cpp` needs to be rewritten for the Windows exception_ptr semantics which copy the exception every time. * `rethrow_if_nested.pass.cpp` need investigation. It hits a stack overflow, likely from recursion. This patch also gets most of the `<future>` tests passing as well. Reviewers: mclow.lists, compnerd, bcraig, rmaprath, majnemer, BillyONeal, STL_MSFT Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D32927 llvm-svn: 302393
* Rename the static version of libc++ on Windows.Eric Fiselier2017-04-201-1/+6
| | | | | | | | | | | Previously both the static version of libc++ and the import library for the DLL had the same name, 'c++.lib'. This patch renames the static library on Windows to be `libc++.lib` so it no longer conflicts. This naming convention is consistent with other windows libraries. llvm-svn: 300817
* [libcxx] Fix check-cxx-abilist on OS XEric Fiselier2017-04-153-14/+12
| | | | | | | | | | | | | | | | | | | | Summary: Recent commits broke the check-cxx-abilist by changing the default OS X to use `-rexport_library` instead of `-reexport_symbol_list`. Apparently `-reexport_library` doesn't export the symbols into `libc++.dylib`s symbol table, whereas `-reexport_symbol_list` does. This means the change removed ~500 symbols from the symbol table. I've been told this change is non ABI breaking, but it does make it harder to maintain the ABI lists, and hence the ABI. This patch fixes the issue by switching back to `-reexport_symbol_list`. It still avoid the issues fixed in r299052 by putting the new/delete symbols in a different symbol list file, which is only exported when LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS in OFF. Reviewers: mehdi_amini, smeenai, dexonsmith Reviewed By: smeenai Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D31644 llvm-svn: 300390
* [CMake][libcxx] Use builtins rather than gcc_s when compiler-rt is requestedPetr Hosek2017-04-051-1/+6
| | | | | | | | | When compiler-rt is requested, we should attempt to link compiler-rt builtins library rather than gcc_s. Differential Revision: https://reviews.llvm.org/D31617 llvm-svn: 299599
* Reexport operator new / delete from libc++abiMehdi Amini2017-03-301-8/+8
| | | | | | | | | | | | | Both libc++ and libc++abi export a weak definition of operator new/delete. On Darwin, this can often cause dirty __DATA in the shared cache when having to switch from one to the other. Instead, libc++ should reexport libc++abi's implementation of these symbols. Patch by: Ted Kremenek <kremenek@apple.com> Differential Revision: https://reviews.llvm.org/D30765 llvm-svn: 299054
* Do not pass an explicit reexported symbol list when building libc++ dylib if ↵Mehdi Amini2017-03-301-1/+5
| | | | | | also defining new/delete llvm-svn: 299052
* [libc++] Add a key function for bad_function_callShoaib Meenai2017-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: bad_function_call is currently an empty class, so any object files using that class will end up with their own copy of its typeinfo, typeinfo name and vtable, leading to unnecessary duplication that has to be resolved by the dynamic linker. Instead, give bad_function_call a key function and put a definition for that key function in libc++ itself, to centralize the typeinfo and vtable. This is consistent with the behavior for other exception classes. The key functions are defined in libc++ rather than libc++abi since the class is defined in the libc++ versioning namespace, so ABI compatibility with libstdc++ is not a concern. Guard this change behind an ABI macro, since it isn't backwards compatible (i.e., clients built against the new libc++ headers wouldn't be able to run against an older libc++ library). Reviewers: mclow.lists, EricWF Subscribers: mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D27387 llvm-svn: 298937
* Change test coverage generation to use llvm-cov instead of gcov.Eric Fiselier2017-03-111-6/+5
| | | | | | | | | | | | | Clang doesn't produce gcov compatible coverage files. This causes lcov to break because it uses gcov by default. This patch switches lcov to use llvm-cov as the gcov-tool. Unfortunatly llvm-cov doesn't provide a gcov like interface by default so it won't work with lcov. However `llvm-cov gcov` does. For this reason we generate 'llvm-cov-wrapper' script that always passes the gcov flag. llvm-svn: 297553
* Remove the buildit and testit scripts; they haven't been supported in yearsEric Fiselier2017-03-031-189/+0
| | | | llvm-svn: 296922
* Update ABI list for 4.0 releaseEric Fiselier2017-03-022-1905/+1906
| | | | llvm-svn: 296805
* [libc++] Make _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS export membersShoaib Meenai2017-03-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building libc++ with hidden visibility, we want explicit template instantiations to export members. This is consistent with existing Windows behavior, and is necessary for clients to be able to link against a hidden visibility built libc++ without running into lots of missing symbols. An unfortunate side effect, however, is that any template methods of a class with an explicit instantiation will get default visibility when instantiated, unless the methods are explicitly marked inline or hidden visibility. This is not desirable for clients of libc++ headers who wish to control their visibility, and led to PR30642. Annotate all problematic methods with an explicit visibility specifier to avoid this. The problematic methods were found by running https://github.com/smeenai/bad-visibility-finder against the libc++ headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS macro, which was created for this purpose. It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally intended to expand to default visibility, and was changed to expanding to default type visibility to fix PR30642. The visibility macro documentation was not updated accordingly, however, so this change makes the macro consistent with its documentation again, while explicitly fixing the methods which resulted in that PR. Differential Revision: https://reviews.llvm.org/D29157 llvm-svn: 296731
* [libc++] Mark some std::num_get method templates inlineShoaib Meenai2017-03-022-19/+37
| | | | | | | | | | | | | | | | | D29157 will make explicit template instantiations expand to default visibility, at which point these method templates will need to be explicitly marked hidden visibility to avoid leaking into other DSOs. Unfortunately, because of clang PR32114, they must be marked inline (in conjunction with `-fvisibility-inlines-hidden`) to actually hide them, since clang doesn't respect the hidden visibility annotation. Since this involves an ABI change, mark these methods inline in a separate change, so that the ABI changes can be reviewed separately and verified to be safe. Differential Revision: https://reviews.llvm.org/D30523 llvm-svn: 296729
* update revision in CHANGELOG.TXT and fix python errorEric Fiselier2017-02-171-2/+2
| | | | llvm-svn: 295399
* Remove more basic_string member function templates from the dylib exportsEric Fiselier2017-02-172-1905/+1916
| | | | llvm-svn: 295398
* Start libc++ python cleanup and consolidation.Eric Fiselier2017-02-092-2/+2
| | | | | | | | | Libc++ frequently creates and uses utilities written in python. Currently there are python modules under both libcxx/test and libcxx/util. My goal with these changes is to consolidate them into a single package under libcxx/utils/libcxx. llvm-svn: 294644
* [libcxx][CMake] Support in-tree libunwind when building as part of runtimesPetr Hosek2017-02-091-2/+2
| | | | | | | | | | | When building as part of runtimes, there is no predefined order in which the runtimes are loaded, so the targets from other projects might not be available. We need to rely on HAVE_<name> variables instead in that case. Differential Revision: https://reviews.llvm.org/D29575 llvm-svn: 294553
* Adjust Apple ABI list after r294133Eric Fiselier2017-02-051-0/+1
| | | | llvm-svn: 294139
* Adjust Linux ABI list after r294133Eric Fiselier2017-02-051-1904/+1905
| | | | llvm-svn: 294138
* Update Linux ABI lists to reflect inlining change in LLVM. More ↵Eric Fiselier2017-01-241-1905/+1904
| | | | | | investigation tomorrow. llvm-svn: 292929
* Fix handling of Apple target triple when checking the ABI lists.Eric Fiselier2017-01-204-3/+10
| | | | | | | | | | | | The check-cxx-abilist rule uses TARGET_TRIPLE to determine which ABI list to check. However the triple on Apple contains the darwin version which changes frequently, but libc++ doesn't need different ABI lists for each darwin version. This patch strips the minor version and patchlevel from TARGET_TRIPLE before using it to determine the ABI list. llvm-svn: 292557
OpenPOWER on IntegriCloud