summaryrefslogtreecommitdiffstats
path: root/libcxx/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros.Eric Fiselier2017-01-131-0/+7
| | | | | | | | | | | | | | | | | | Clang recently added a `diagnose_if(cond, msg, type)` attribute which can be used to generate diagnostics when `cond` is a constant expression that evaluates to true. Otherwise no attribute has no effect. This patch adds _LIBCPP_DIAGNOSE_ERROR/WARNING macros which use this new attribute. Additionally this patch implements a diagnostic message when a non-const-callable comparator is given to a container. Note: For now the warning version of the diagnostic is useless within libc++ since warning diagnostics are suppressed by the system header pragma. I'm going to work on fixing this. llvm-svn: 291961
* Update version to 5.0Eric Fiselier2017-01-131-2/+2
| | | | llvm-svn: 291928
* [libc++] Correct macro name in documenationShoaib Meenai2017-01-071-1/+1
| | | | | | | The macro is named `_LIBCPP_TEMPLATE_VIS`, not `_LIBCPP_TEMPLATE_ONLY`. No functional change. llvm-svn: 291330
* [libc++] Cleanup and document <__threading_support>Eric Fiselier2017-01-062-1/+71
| | | | | | | | | | | | | | | Summary: This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses. The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API. Reviewers: compnerd, rmaprath Subscribers: smeenai, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D28316 llvm-svn: 291275
* Fix Sphinx build error caused by bad indentationEric Fiselier2017-01-051-1/+1
| | | | llvm-svn: 291039
* [NFC] Rename _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VISEric Fiselier2017-01-041-6/+7
| | | | | | | | | | | | | 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
* Update year to 2017Eric Fiselier2017-01-031-1/+1
| | | | llvm-svn: 290876
* Remove dead debug_mode doc linkEric Fiselier2016-12-281-1/+0
| | | | llvm-svn: 290659
* Implement a throwing version of _LIBCPP_ASSERT.Eric Fiselier2016-12-283-11/+102
| | | | | | | | | | | | | | | | | | | | | | | | | This patch implements changes to allow _LIBCPP_ASSERT to throw on failure instead of aborting. The main changes needed to do this are: 1. Change _LIBCPP_ASSERT to call a handler via a replacable function pointer instead of calling abort directly. Additionally this patch implements two handler functions, one which aborts and another that throws an exception. 2. Add _NOEXCEPT_DEBUG macro for disabling noexcept spec on function which contain _LIBCPP_ASSERT. This is required in order to prevent assertion failures throwing through a noexcept function. This macro has no effect unless _LIBCPP_DEBUG_USE_EXCEPTIONS is defined. Having a non-aborting _LIBCPP_ASSERT is very important to allow sane testing of debug mode. Currently we can only have one test case per file, since the test case will cause the program to abort. Testing debug mode this way would require thousands of test files, most of which would be 95% boiler plate. I don't think this is a feasible strategy. Fortunately using a throwing debug handler solves these issues. Additionally this patch rewrites the documentation for debug mode. llvm-svn: 290651
* Update TestingLibcxx doc to reflect the use_system_cxx_lib flag. Patch from ↵Eric Fiselier2016-12-231-3/+3
| | | | | | Michael Park llvm-svn: 290441
* Update doc version to 4.0Eric Fiselier2016-12-091-2/+2
| | | | llvm-svn: 289206
* [NFC] Change whitespace to force docs rebuildEric Fiselier2016-12-091-0/+1
| | | | llvm-svn: 289205
* Fix PR27374 - Remove the implicit reduced-arity-extension in tuple.Eric Fiselier2016-12-081-0/+27
| | | | | | | | | | | | | | | | | | | This patch removes libc++'s tuple extension which allowed it to be constructed from fewer initializers than elements; with the remaining elements being default constructed. However the implicit version of this extension breaks conforming code. For example: int fun(std::string); int fun(std::tuple<std::string, int>); int x = fun("hello"); // ambigious Because existing code may already depend on this extension it can be re-enabled by defining _LIBCPP_ENABLE_TUPLE_IMPLICIT_REDUCED_ARITY_EXTENSION. Note that the explicit version of this extension is still supported, although it's somewhat less useful than the implicit one. llvm-svn: 289158
* [libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONSShoaib Meenai2016-12-051-0/+6
| | | | | | | | | | | It's useful to be able to disable visibility annotations entirely; for example, if we're building libc++ static to include in another library, and we don't want any libc++ functions getting exported out of that library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT. Differential Revision: https://reviews.llvm.org/D26934 llvm-svn: 288690
* [libc++] Introduce `_LIBCPP_OVERRIDABLE_FUNC_VIS`Shoaib Meenai2016-11-161-14/+12
| | | | | | | | | | This is a generalization of `_LIBCPP_NEW_DELETE_VIS`; the new macro name captures the semantics better, and also allows us to get rid of the `_WIN32` check in `include/new`. No functional change. Differential Revision: https://reviews.llvm.org/D26702 llvm-svn: 287164
* Add docs for use-configurable libc++ featuresEric Fiselier2016-11-131-0/+26
| | | | llvm-svn: 286784
* Fix _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to always have default visibility.Eric Fiselier2016-10-311-6/+5
| | | | | | | | | | | This prevent the symbols from being both externally available and hidden, which causes them to be linked incorrectly. This is only a problem when the address of the function is explicitly taken since it will always be inlined otherwise. This patch fixes the issues that caused r285456 to be reverted, and can now be reapplied. llvm-svn: 285531
* Add start of filesystem benchmarksEric Fiselier2016-10-301-5/+12
| | | | llvm-svn: 285524
* Cleanup LIT testing docEric Fiselier2016-10-141-12/+14
| | | | llvm-svn: 284205
* [libc++] Correct explanation of _LIBCPP_NEW_DELETE_VISShoaib Meenai2016-10-121-8/+9
| | | | | | | | | | The behavior of this macro actually needs to apply universally on Windows and not just when using the Microsoft CRT. Update the macro definition and documentation accordingly. Differential Revision: https://reviews.llvm.org/D25145 llvm-svn: 284016
* Make it easier to run the libc++ test suite against libstdc++Eric Fiselier2016-10-121-3/+9
| | | | llvm-svn: 283958
* [libc++] Clarify _LIBCPP_NEW_DELETE_VIS for WindowsShoaib Meenai2016-09-281-0/+13
| | | | | | | | | | | | | | | | | | Replace a stale reference to cxx_EXPORTS with _LIBCPP_BUILDING_LIBRARY, and clarify why the operator new and delete family of functions are marked dllexport when building but *not* dllimport when including the header externally. The new code is identical to the intent of the old code (and would be functionally equivalent were cxx_EXPORTS still defined when building libc++). The overall behavior is not ideal, since Microsoft's operator new and delete functions will get called instead of libc++'s, but I think consistently calling msvcrt's functions is better than either calling msvcrt's or libc++'s functions depending on header inclusion. Differential Revision: https://reviews.llvm.org/D25042 llvm-svn: 282644
* [libc++] Fix extern template visibility for WindowsShoaib Meenai2016-09-191-0/+20
| | | | | | | | | | On Windows, marking an `extern template class` declaration as exported actually forces an instantiation, which is not the desired behavior. Instead, the actual explicit instantiations need to be exported. Differential Revision: https://reviews.llvm.org/D24679 llvm-svn: 281925
* Attempt to fix Sphinx buildEric Fiselier2016-09-163-9/+9
| | | | llvm-svn: 281697
* Update _LIBCPP_EXCEPTION_ABI doc with @mclow's feedbackEric Fiselier2016-09-161-2/+3
| | | | llvm-svn: 281695
* [libc++] Add _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY to support GCC ABI ↵Eric Fiselier2016-09-161-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compatibility Summary: GCC and Clang handle visibility attributes on the out-of-line definition of externally instantiated templates differently. For example in the reproducer below Clang will emit both 'foo' and 'bar' with default visibility while GCC only emits a non-hidden 'foo'. ``` // RUN: g++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out // RUN: clang++ -std=c++11 -shared -O3 test.cpp && sym_extract.py a.out #define INLINE_VISIBILITY __attribute__((visibility("hidden"), always_inline)) template <class T> struct Foo { void foo(); void bar(); }; template <class T> void Foo<T>::foo() {} template <class T> inline INLINE_VISIBILITY void Foo<T>::bar() {} template struct Foo<int>; ``` This difference creates ABI incompatibilities between Clang and GCC built dylibs. Specifically GCC built dylibs lack definitions for various member functions of `basic_string`, `basic_istream`, `basic_ostream`, `basic_iostream`, and `basic_streambuf` (All of these types are externally instantiated). Surprisingly these missing symbols don't cause many problems because the functions are marked `always_inline` therefore the dylib definition is rarely needed. However when an out-of-line definition is required then GCC built dylibs will fail to link. For example [GCC built dylibs cannot build Clang](http://stackoverflow.com/questions/39454262/clang-build-errors). This patch works around this issue by adding `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` which is used to mark externally instantiated member functions as always inline. When building the library `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` sets the symbol's visibility to "default" instead of "hidden", otherwise it acts exactly the same as `_LIBCPP_INLINE_VISIBILITY`. After applying this patch GCC dylibs now contain: * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7sungetcEv` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5gbumpEi` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7sungetcEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9sputbackcEc` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERNS_15basic_streambufIwS2_EE` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_9basic_iosIwS2_EES6_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setpEPcS4_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6snextcEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE4swapERS3_` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcm` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE9pubsetbufEPcl` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekoffExNS_8ios_base7seekdirEj` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_9basic_iosIwS2_EES6_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5pbumpEi` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpENS_4fposI11__mbstate_tEE` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE7getlineEPcl` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetcEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8in_availEv` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE6sbumpcEv` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRNS_9basic_iosIcS2_EES6_E` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getERc` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6snextcEv` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEmw` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE7getlineEPwl` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5tellpEv` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getERw` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEmc` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE7pubsyncEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEE3getEPcl` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRNS_9basic_iosIcS2_EES6_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE7pubsyncEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputcEc` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpExNS_8ios_base7seekdirE` * `_ZNKSt3__115basic_streambufIcNS_11char_traitsIcEEE6getlocEv` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5gbumpEi` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5seekpENS_4fposI11__mbstate_tEE` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE5tellpEv` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRS3_S4_E` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEE3getEPwl` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE4setgEPcS4_S4_` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwmm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setgEPwS4_S4_` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEEC1EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE8pubimbueERKNS_6localeE` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE4swapERS3_` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEEC2EPNS_15basic_streambufIwS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekposENS_4fposI11__mbstate_tEEj` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5pbumpEi` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetcEv` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEE4swapERS3_` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE10pubseekposENS_4fposI11__mbstate_tEEj` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sputnEPKcl` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEE5seekpExNS_8ios_base7seekdirE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sgetnEPwl` * `_ZNSt3__113basic_ostreamIwNS_11char_traitsIwEEElsEPFRNS_8ios_baseES5_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE4setpEPwS4_` * `_ZNSt3__115basic_streambufIcNS_11char_traitsIcEEE5sgetnEPcl` * `_ZNKSt3__115basic_streambufIwNS_11char_traitsIwEEE6getlocEv` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8pubimbueERKNS_6localeE` * `_ZNSt3__114basic_iostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE8in_availEv` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEE6__initEPKcmm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE6sbumpcEv` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE10pubseekoffExNS_8ios_base7seekdirEj` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC2EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__113basic_istreamIwNS_11char_traitsIwEEErsEPFRS3_S4_E` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9sputbackcEw` * `_ZNSt3__112basic_stringIwNS_11char_traitsIwEENS_9allocatorIwEEE6__initEPKwm` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputnEPKwl` * `_ZNSt3__113basic_istreamIcNS_11char_traitsIcEEErsEPFRS3_S4_E` * `_ZNSt3__113basic_ostreamIcNS_11char_traitsIcEEEC1EPNS_15basic_streambufIcS2_EE` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE9pubsetbufEPwl` * `_ZNSt3__115basic_streambufIwNS_11char_traitsIwEEE5sputcEw` This patch has no effect on Clang based builds. Reviewers: mclow.lists, eugenis, danalbert, jroelofs, EricWF Subscribers: beanz, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D24600 llvm-svn: 281681
* [libc++] Fix and document visibility attributes for Clang, GCC and Windows.Eric Fiselier2016-09-152-0/+86
| | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each! This patch adds two new visibility macros: * `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this. * `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this. After applying this patch GCC only emits one -Wattribute warning opposed to 30+. Reviewers: mclow.lists, EricWF Subscribers: beanz, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D24602 llvm-svn: 281673
* Enable installation of libc++experimental by default.Eric Fiselier2016-09-071-1/+1
| | | | | | | | | | | | When libc++experimental was originally created it was empty and therefore there was no reason to install it. Now that the library contains <experimental/memory_resource> and <experimental/filesystem> there is a good reason to install it. Specifically this patch enables the installation whenever LIBCXX_INSTALL_LIBRARY is true and LIBCPP_ENABLE_EXPERIMENTAL_LIBRARY is true. llvm-svn: 280773
* Turn On -DLIBCXX_ENABLE_BENCHMARKS by default.Eric Fiselier2016-08-292-7/+6
| | | | | | | | | | | | | | This patch enables the `cxx-benchmarks` target by default. Note that the target still has to be manually invoked since it isn't included in the default 'make' rule. This patch also gets the benchmarks building w/ GCC. The build previously required the '-stdlib=libc++' flag but upstream patches to Google Benchmark now allow the library to build w/ libc++ and GCC. These changes should make the benchmarks easier to build and test. llvm-svn: 279999
* [Docs] Update libc++ target names after r279675.Eric Fiselier2016-08-281-2/+2
| | | | llvm-svn: 279940
* Allow building both shared and static libraryPetr Hosek2016-08-081-2/+9
| | | | | | | | | This change allows building both shared and static version of libc++ in a single build, sharing object files between both versions. Differential Revision: https://reviews.llvm.org/D23232 llvm-svn: 278068
* [libcxx] Add support for benchmark tests using Google Benchmark.Eric Fiselier2016-07-192-3/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch does the following: 1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`. 2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL. 3. Allows performance benchmarks to be built as part of the libc++ build. Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target. On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries. Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions. Known Issues: * `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark. Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel Differential Revision: https://reviews.llvm.org/D22240 llvm-svn: 276049
* Add Filesystem TS -- CompleteEric Fiselier2016-06-171-0/+8
| | | | | | | | | | | | | | Add the completed std::experimental::filesystem implementation and tests. The implementation supports C++11 or newer. The TS is built as part of 'libc++experimental.a'. Users of the TS need to manually link this library. Building and testing the TS can be disabled using the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'. Currently 'libc++experimental.a' is not installed by default. To turn on the installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'. llvm-svn: 273034
* Update libcxx.llvm.org documentation by linking to new docs.Eric Fiselier2016-06-021-0/+70
| | | | | | | | | | | | | | | Summary: Currently much of the libcxx website is duplicated between the old www/ documentation and newer Sphinx docs. This patch changes the main libc++ webpage so that it links to the new documentation where possible. This means removing numerous sections from the landing page. @mclow.lists What do you think? Reviewers: mclow.lists Subscribers: cfe-commits, mclow.lists Differential Revision: http://reviews.llvm.org/D19250 llvm-svn: 271469
* Fix errors in documentationEric Fiselier2016-05-061-1/+1
| | | | llvm-svn: 268709
* Fix sphinx build. This is a temporary solution.Eric Fiselier2016-05-051-12/+12
| | | | llvm-svn: 268614
* Try and fix sphinx buildEric Fiselier2016-05-051-8/+8
| | | | llvm-svn: 268613
* Update version numbers in docsEric Fiselier2016-05-031-3/+3
| | | | llvm-svn: 268459
* Add documentation for new experimental libraryEric Fiselier2016-05-032-0/+56
| | | | llvm-svn: 268456
* Add cxx_runtime_root options for testing against a different libc++ at runtimeEric Fiselier2016-04-201-4/+13
| | | | llvm-svn: 266855
* [docs] Remove references to autoconf build.Alexey Samsonov2016-01-301-2/+1
| | | | llvm-svn: 259281
* Add link to 3rd party GDB pretty-printersEric Fiselier2016-01-201-0/+13
| | | | llvm-svn: 258270
* Update paths in libc++ build instructions. Patch from Jonathan Anderson.Eric Fiselier2015-12-141-2/+2
| | | | llvm-svn: 255561
* [libcxx] Make libc++.so a linker script by default on most platforms.Eric Fiselier2015-10-152-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch turns on `LIBCXX_ENABLE_ABI_LINKER_SCRIPT` by default whenever `LLVM_HAVE_LINK_VERSION_SCRIPT` is ON. This turns out to be whenever: 1. WIN32 is not defined. 2 UNIX is defined. 3. APPLE is not defined. While `LLVM_HAVE_LINK_VERSION_SCRIPT` is meant to reflect exactly what we are asking I think it's close enough. After committing this patch Linux users will no longer have to use "-lc++abi" explicitly! Reviewers: mclow.lists, danalbert, compnerd, jroelofs Subscribers: emaste, rengolin, cbergstrom, cfe-commits Differential Revision: http://reviews.llvm.org/D13739 llvm-svn: 250469
* Add links to libc++ code coverage and buildersEric Fiselier2015-10-151-2/+4
| | | | llvm-svn: 250361
* Update testing guide for libc++Eric Fiselier2015-10-141-7/+56
| | | | llvm-svn: 250323
* Use __config_site when building libc++. Also cleanup ABI versioning docEric Fiselier2015-10-142-0/+1
| | | | llvm-svn: 250261
* ABI versioning macros for libc++.Evgeniy Stepanov2015-10-132-0/+36
| | | | | | | | C++ macros and CMake options that specify the default ABI version of the library, and can be overridden to pick up new ABI-changing features. llvm-svn: 250254
* Fix whitespace in docEric Fiselier2015-10-131-1/+1
| | | | llvm-svn: 250238
* [libcxx] Capture configuration information when installing the libc++ headersEric Fiselier2015-10-132-0/+94
| | | | | | | | | | | | | | | | | Summary: Hi all, This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread. Please read the design documentation added in this patch for a description of how it works. Reviewers: mclow.lists, danalbert, jroelofs, EricWF Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits Differential Revision: http://reviews.llvm.org/D13407 llvm-svn: 250235
OpenPOWER on IntegriCloud