summaryrefslogtreecommitdiffstats
path: root/libcxx/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* [libcxx] Remove custom CMake code targeting Mac OS 10.6Louis Dionne2018-10-161-1/+1
| | | | | | | | | | | | | libc++ has dropped support for Mac OS 10.6 for a while, and we don't have any testers set up for that OS. This commit puts in an error message so that people can reach out to the libc++ maintainers in case support for 10.6 is still expected (as opposed to silently failing in weird ways). We can completely drop support for 10.6 and remove the error message some time in the future when we're sure that nobody is relying on it. llvm-svn: 344576
* [libc++] Add deprecated attributes to many deprecated componentsLouis Dionne2018-09-231-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These deprecation warnings are opt-in: they are only enabled when the _LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case by default. Note that this is a first step in the right direction, but I wasn't able to get an exhaustive list of all deprecated components per standard, so there's certainly stuff that's missing. The list of components this commit marks as deprecated is: in C++11: - auto_ptr, auto_ptr_ref - binder1st, binder2nd, bind1st(), bind2nd() - pointer_to_unary_function, pointer_to_binary_function, ptr_fun() - mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun() - mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref() in C++14: - random_shuffle() in C++17: - unary_negate, binary_negate, not1(), not2() <rdar://problem/18168350> Reviewers: mclow.lists, EricWF Subscribers: christof, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48912 llvm-svn: 342843
* Correct docs to reference the new libc++ lists.Eric Fiselier2018-09-221-9/+6
| | | | | | | | We recently added libcxx-dev and libcxx-commits mailing lists. This patch updates the libc++ documentation to correctly reference the libc++ lists instead of the old Clang ones. llvm-svn: 342816
* [libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow ↵Roman Lebedev2018-09-221-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pre-C++2a [[nodiscard]] Summary: The `[[nodiscard]]` attribute is intended to help users find bugs where function return values are ignored when they shouldn't be. After C++17 the C++ standard has started to declared such library functions as `[[nodiscard]]`. However, this application is limited and applies only to dialects after C++17. Users who want help diagnosing misuses of STL functions may desire a more liberal application of `[[nodiscard]]`. For this reason libc++ provides an extension that does just that! The extension must be enabled by defining `_LIBCPP_ENABLE_NODISCARD`. The extended applications of `[[nodiscard]]` takes two forms: 1. Backporting `[[nodiscard]]` to entities declared as such by the standard in newer dialects, but not in the present one. 2. Extended applications of `[[nodiscard]]`, at the libraries discretion, applied to entities never declared as such by the standard. Users may also opt-out of additional applications `[[nodiscard]]` using additional macros. Applications of the first form, which backport `[[nodiscard]]` from a newer dialect may be disabled using macros specific to the dialect it was added. For example `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`. Applications of the second form, which are pure extensions, may be disabled by defining `_LIBCPP_DISABLE_NODISCARD_EXT`. This patch was originally written by me (Roman Lebedev), then but then reworked by Eric Fiselier. Reviewers: mclow.lists, thakis, EricWF Reviewed By: thakis, EricWF Subscribers: llvm-commits, mclow.lists, lebedev.ri, EricWF, rjmccall, Quuxplusone, cfe-commits, christof Differential Revision: https://reviews.llvm.org/D45179 llvm-svn: 342808
* fix some typos in the docSylvestre Ledru2018-09-203-5/+5
| | | | llvm-svn: 342628
* refresh the libc++ homepageSylvestre Ledru2018-09-201-3/+3
| | | | llvm-svn: 342624
* ReleaseNotes: update links to use httpsHans Wennborg2018-09-101-6/+6
| | | | llvm-svn: 341789
* [libc++] Add a link to the Release notes from the main libc++ documentationLouis Dionne2018-09-061-0/+1
| | | | llvm-svn: 341551
* [libcxx] Add ReleaseNotes.rst file for release notesLouis Dionne2018-09-061-0/+43
| | | | llvm-svn: 341550
* [libcxx] By default, do not use internal_linkage to hide symbols from the ABILouis Dionne2018-08-162-3/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and we expect this may be the case in other projects built in debug mode too. Instead, unless users explicitly ask for internal_linkage, we use always_inline like we used to. In the future, when we have a solution that allows us to drop always_inline without falling back on internal_linkage, we can replace always_inline by that. Note that this commit introduces a change in contract for existing libc++ users: by default, libc++ used to guarantee that TUs built with different versions of libc++ could be linked together. With the introduction of the _LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built with different libc++ versions are not guaranteed to link. This is a change in contract but not a change in behavior, since the current implementation still allows linking TUs built with different libc++ versions together. Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk Subscribers: christof, cfe-commits Differential Revision: https://reviews.llvm.org/D50652 llvm-svn: 339874
* [libc++] Add the _LIBCPP_HIDE_FROM_ABI_AFTER_V1 macroLouis Dionne2018-08-061-9/+15
| | | | | | | | | | | | | | | | | | | | | Summary: This macro allows hiding symbols from the ABI when the library is built with an ABI version after ABI v1, which is currently the only stable ABI. This commit defines `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` to be `_LIBCPP_HIDE_FROM_ABI_AFTER_V1`, meaning that symbols that were only exported by the library for historical reasons are not exported anymore in the unstable ABI. Because of that, this commit is an ABI break for ABI v2. This ABI version is not stable, however, so this should not be a problem. Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D49914 llvm-svn: 339012
* Update version to 8.0.0svn: cmake, includes files and docsHans Wennborg2018-08-011-3/+3
| | | | llvm-svn: 338555
* [libc++] Introduce _LIBCPP_HIDE_FROM_ABI to replace _LIBCPP_INLINE_VISIBILITYLouis Dionne2018-07-271-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to mark functions that shouldn't be part of libc++'s ABI. It marks the functions as being hidden for dylib visibility purposes, and as having internal linkage using Clang's __attribute__((internal_linkage)) when available, and __always_inline__ otherwise. It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__ to achieve similar goals, but suffered from debuggability and code size problems. The full proposal, along with more background information, can be found here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to _LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can be done later when we've confirmed we're happy with the new macro. In the future, it would be nice if we could optionally allow dropping any internal_linkage or __always_inline__ attribute, which could result in code size improvements. However, this is currently impossible for reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html Reviewers: EricWF, dexonsmith, mclow.lists Subscribers: christof, dexonsmith, llvm-commits, mclow.lists Differential Revision: https://reviews.llvm.org/D49240 llvm-svn: 338122
* Implement <filesystem>Eric Fiselier2018-07-272-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC] Fix grammatical mistakes in libc++ FileTimeType design docsLouis Dionne2018-07-251-10/+10
| | | | llvm-svn: 337925
* Fix another typo in the FileTimeType docsEric Fiselier2018-07-251-1/+1
| | | | llvm-svn: 337900
* Fix typos, spelling, and grammar in the FileTimeType design docs.Eric Fiselier2018-07-251-36/+37
| | | | | | I'm sure I'll discover more mistakes as I go on... llvm-svn: 337897
* Add design docs for upcoming file_time_type change.Eric Fiselier2018-07-253-1/+495
| | | | | | | | | | | | | | | | | | In upcoming changes to filesystem I plan to change file_time_type to use __int128_t as its underlying representation, in order to allow it to have a range and resolution at least that of the timespec struct. There was some pushback against this decision, so I drafted a document explaining the problems, potential solutions, and the rational for the decision. However, it's probably easier to let people read the generated HTML rather than the raw restructured text. For this reason I'm commiting the design documents before hand, so they can be available during any subsequent discussion or code review. llvm-svn: 337880
* [libc++] Take 2: Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Note that this commit had originally been applied in r336369 and then reverted in r336382 because of unforeseen problems. Both of these problems have now been fixed. Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, erikvanderpoel Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336866
* Revert "[libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by ↵Louis Dionne2018-07-051-4/+4
| | | | | | | | | | | | | | | _LIBCPP_INLINE_VISIBILITY" This reverts commit r336369. The commit had two problems: 1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of _LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the dylib and the check-cxx-abilist failing. 2. The LLDB tests started failing because they undefine `_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and fix the tests before we can go forward with this change. llvm-svn: 336382
* [libc++] Replace uses of _LIBCPP_ALWAYS_INLINE by _LIBCPP_INLINE_VISIBILITYLouis Dionne2018-07-051-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: We never actually mean to always inline a function -- all the uses of the macro I could find are actually attempts to control the visibility of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which is actually always defined the same. This change is orthogonal to the decision of what we're actually going to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by having one canonical way of doing things. Reviewers: EricWF Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists Differential Revision: https://reviews.llvm.org/D48892 llvm-svn: 336369
* Fix typos.Bruce Mitchener2018-02-132-2/+2
| | | | | | | | | | Reviewers: mclow.lists, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43224 llvm-svn: 324989
* [cmake] Add a config option LIBCXX_HAS_WIN32_THREAD_API for enforcing win32 ↵Martin Storsjo2018-01-051-0/+4
| | | | | | | | | | | | | | | | threads This allows keeping libcxx using win32 threads even if a version of pthread.h is installed. This matches the existing cmake option LIBCXX_HAS_PTHREAD_API. Also add missing documentation about the internal define _LIBCPP_HAS_THREAD_API_WIN32. Differential Revision: https://reviews.llvm.org/D41764 llvm-svn: 321896
* Update version to 7.0.0svn: cmake, include files and docsHans Wennborg2018-01-031-2/+2
| | | | llvm-svn: 321725
* Corrected a typo in the building libc++ docsHamza Sood2017-12-031-1/+1
| | | | llvm-svn: 319631
* Teach test suite about C++2a dialect flag.Eric Fiselier2017-11-071-1/+1
| | | | | | | | This patch teaches the test suite configuration about the -std=c++2a flag. And, since it's the newest dialect, change the test suite to choose it, if possible, by default. llvm-svn: 317611
* Change test suite to support c++17 dialect flag instead of c++1z.Eric Fiselier2017-11-071-1/+1
| | | | | | | | This patch changes the test suite to attempt and prefer -std=c++17 over -std=c++1z. It also fixes the REQUIRES and UNSUPPORTED lit markers to refer to c++17 over c++1z. llvm-svn: 317610
* [libc++] Support Microsoft ABI without vcruntime headersShoaib Meenai2017-10-091-0/+20
| | | | | | | | | | | | | | | | | The vcruntime headers are hairy and clash with both libc++ headers themselves and other libraries. libc++ normally deals with the clashes by deferring to the vcruntime headers and silencing its own definitions, but for clients which don't want to depend on vcruntime headers, it's desirable to support the opposite, i.e. have libc++ provide its own definitions. Certain operator new/delete replacement scenarios are not currently supported in this mode, which requires some tests to be marked XFAIL. The added documentation has more details. Differential Revision: https://reviews.llvm.org/D38522 llvm-svn: 315234
* [libc++] Add site config option for ABI macrosShoaib Meenai2017-10-041-0/+7
| | | | | | | | | | | | | | | | | Some ABI macros affect headers, so it's nice to have a site config option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow specifying a list of ABI macros to define in the site config. The primary design constraint (as discussed with Eric on IRC a while back) was to not have to repeat the ABI macro names in cmake, which only leaves a free-form cmake list as an option. A somewhat unfortunate consequence is that we can't verify that the ABI macros being defined actually exist, though we can at least perform some basic sanity checking, since all the ABI macros begin with _LIBCPP_ABI_. Differential Revision: https://reviews.llvm.org/D36719 llvm-svn: 314946
* Bump docs version to 6.0Hans Wennborg2017-07-191-2/+2
| | | | llvm-svn: 308462
* [libc++] class template -> template class. NFCShoaib Meenai2017-07-131-1/+1
| | | | llvm-svn: 307972
* [libc++] Mark string operator+ _LIBCPP_FUNC_VISShoaib Meenai2017-07-131-1/+2
| | | | | | | | | | | | | | | It has an extern template instantiation declaration in the headers and a corresponding instantiation definition in the library, so we must mark it with _LIBCPP_FUNC_VIS to make it available outside the library. This doesn't cause any ABI changes as-is since we don't build libc++ with hidden visibility (so the function is exported anyway). It's needed for building libc++ with hidden visibility, however. Clarify the Windows behavior for extern function templates while I'm here, since this exercises that behavior. llvm-svn: 307966
* [libc++] Use proper template terminology. NFCShoaib Meenai2017-07-131-3/+3
| | | | | | | It's supposed to be "class template" and "function template" instead of "template class" and "template function". llvm-svn: 307954
* [libcxx][CMake] Add install path variable to allow overriding the destinationPetr Hosek2017-07-111-0/+5
| | | | | | | | | 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
* Fix misspelling of environment throughout libc++Eric Fiselier2017-05-091-1/+1
| | | | llvm-svn: 302600
* docs: Fix Sphinx detection with out-of-tree buildsTom Stellard2017-05-091-2/+2
| | | | | | Adapt to changes made in r302499. llvm-svn: 302517
* Add markup for libc++ dylib availabilityMehdi Amini2017-05-042-0/+115
| | | | | | | | | | | | | | | Libc++ is used as a system library on macOS and iOS (amongst others). In order for users to be able to compile a binary that is intended to be deployed to an older version of the platform, clang provides the availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_ that can be placed on declarations to describe the lifecycle of a symbol in the library. See docs/DesignDocs/AvailabilityMarkup.rst for more information. Differential Revision: https://reviews.llvm.org/D31739 llvm-svn: 302172
* Update Appveyor bot link to point to new llvm-mirror Appveyor accountEric Fiselier2017-05-041-1/+1
| | | | llvm-svn: 302128
* update buildbot doc to link to the new Appveyor buildersEric Fiselier2017-05-041-1/+1
| | | | llvm-svn: 302116
* [libc++] Add _LIBCPP_DISABLE_EXTERN_TEMPLATE config optionShoaib Meenai2017-04-131-0/+5
| | | | | | | | | | | | | | | | | | When the libc++ extern template macros were added, the intent was for it to be possible for consumers of the headers to disable extern templates (via `-D_LIBCPP_EXTERN_TEMPLATE(...)=`). Unfortunately, support for specifying function-like macros varies on the command line varies across compilers (e.g. MSVC doesn't support it at all), and cmake doesn't allow it for the same reason. Add a non-function macro for this purpose. The intended use is for libraries which want to use the libc++ headers without taking a dependency on the libc++ library itself. I can name the macro something which reflects its intent rather than its behavior (e.g. `_LIBCPP_HEADER_ONLY`) if desired. Differential Revision: https://reviews.llvm.org/D31725 llvm-svn: 300246
* [libc++] Make _LIBCPP_TYPE_VIS export membersShoaib Meenai2017-03-021-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some of their members exported, otherwise we have a lot of link errors when linking against a libc++ built with hidden visibility. This also makes _LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it already exports members. With this change made, any template methods of a class marked _LIBCPP_TYPE_VIS will also get default visibility when instantiatied, which is not desirable for clients of libc++ headers who wish to control their visibility; this is the same issue as PR30642. Annotate all problematic methods with an explicit visibility specifier to avoid this. The problematic methods were found by running bad-visibility-finder [1] against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The small methods were marked for inlining; the larger ones hidden. [1] https://github.com/smeenai/bad-visibility-finder Reviewers: mclow.lists, EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D25208 llvm-svn: 296732
* [libc++] Make _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS export membersShoaib Meenai2017-03-021-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Update all bug URL's to point to https://bugs.llvm.org/...Eric Fiselier2017-02-171-2/+2
| | | | llvm-svn: 295434
* Add doc for _LIBCPP_ENABLE_CXX17_DISABLED_AUTO_PTR and make it work under ↵Eric Fiselier2017-02-171-2/+4
| | | | | | _LIBCPP_ENABLE_CXX17_REMOVED_FEATURES llvm-svn: 295407
* [libcxx] Remove unexpected handlers in C++17Eric Fiselier2017-02-171-0/+10
| | | | | | | | | | | | | | | | | | | Summary: This patch implements [P0003R5](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html) which removes exception specifications from C++17. The only changes to the library are removing `set_unexpected`, `get_unexpected`, `unexpected`, and `unexpected_handler`. These functions can be re-enabled in C++17 using `_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS`. @mclow.lists what do you think about removing stuff is this way? Reviewers: mclow.lists Reviewed By: mclow.lists Subscribers: mclow.lists, cfe-commits Differential Revision: https://reviews.llvm.org/D28172 llvm-svn: 295406
* docs: add some documentation for building on WindowsSaleem Abdulrasool2017-02-101-0/+51
| | | | | | | | | This covers how to build libc++ for Windows. This allows others to replicate the MS ABI style build for libc++. It only depends on msvcrt as it uses the Windows threading model and the Windows ABI and can serve as an ABI compatible replacement for msvcprt. llvm-svn: 294705
* Fix typo in docsEric Fiselier2017-02-051-1/+1
| | | | llvm-svn: 294115
* [libcxx] Mentions "targeting C++11 and above" instead of "targeting C++11" ↵Mehdi Amini2017-01-251-1/+2
| | | | | | in the doc llvm-svn: 293071
* [libc++] Introduce _LIBCPP_EXTERN_VIS to fix __libcpp_debug_function link errorsEric Fiselier2017-01-161-0/+6
| | | | | | | | | | | | | | Summary: On Windows tests that use `_LIBCPP_ASSERT` fail to link because the assertion handler function isn't correctly exported from the libc++ dylib. This patch fixes the dll import/export issues by introducing a new visibility macro `_LIBCPP_EXTERN_VIS` for use on external variables. Reviewers: compnerd, smeenai, EricWF Reviewed By: EricWF Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28728 llvm-svn: 292158
* [libcxx] Improve design documentation for the external-thread-libraryAsiri Rathnayake2017-01-161-7/+16
| | | | | | | | | | | configuration NFC. Differential revision: https://reviews.llvm.org/D28610 Reviewers: EricWF llvm-svn: 292108
OpenPOWER on IntegriCloud