maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/libcxx/docs/UsingLibcxx.rst

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

348 lines
13 KiB
ReStructuredText
Raw Normal View History

[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
.. _using-libcxx:
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
============
Using libc++
============
.. contents::
:local:
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
Usually, libc++ is packaged and shipped by a vendor through some delivery vehicle
(operating system distribution, SDK, toolchain, etc) and users don't need to do
anything special in order to use the library.
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
This page contains information about configuration knobs that can be used by
users when they know libc++ is used by their toolchain, and how to use libc++
when it is not the default library used by their toolchain.
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
Using a different version of the C++ Standard
=============================================
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
Libc++ implements the various versions of the C++ Standard. Changing the version of
the standard can be done by passing ``-std=c++XY`` to the compiler. Libc++ will
automatically detect what Standard is being used and will provide functionality that
matches that Standard in the library.
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
.. code-block:: bash
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
$ clang++ -std=c++17 test.cpp
[libc++] Re-document how to use <filesystem> with various versions of libc++ This documentation was removed when we added <filesystem> to the dylib in r356518, but it really should have been updated to reflect the new state of things. Keeping documentation around doesn't hurt and users will have an easier time migrating. llvm-svn: 356681
2019-03-22 00:21:09 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
.. warning::
Using ``-std=c++XY`` with a version of the Standard that has not been ratified yet
is considered unstable. Libc++ reserves the right to make breaking changes to the
library until the standard has been ratified.
[libc++] Re-document how to use <filesystem> with various versions of libc++ This documentation was removed when we added <filesystem> to the dylib in r356518, but it really should have been updated to reflect the new state of things. Keeping documentation around doesn't hurt and users will have an easier time migrating. llvm-svn: 356681
2019-03-22 00:21:09 +08:00
Implement <filesystem> 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
2018-07-27 11:07:09 +08:00
Add documentation for new experimental library llvm-svn: 268456
2016-05-04 06:32:08 +08:00
Using libc++experimental and ``<experimental/...>``
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
===================================================
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
Add documentation for new experimental library llvm-svn: 268456
2016-05-04 06:32:08 +08:00
Libc++ provides implementations of experimental technical specifications
in a separate library, ``libc++experimental.a``. Users of ``<experimental/...>``
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
headers may be required to link ``-lc++experimental``. Note that not all
vendors ship ``libc++experimental.a``, and as a result, you may not be
able to use those experimental features.
Add documentation for new experimental library llvm-svn: 268456
2016-05-04 06:32:08 +08:00
.. code-block:: bash
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
$ clang++ test.cpp -lc++experimental
Add documentation for new experimental library llvm-svn: 268456
2016-05-04 06:32:08 +08:00
.. warning::
Experimental libraries are Experimental.
* The contents of the ``<experimental/...>`` headers and ``libc++experimental.a``
library will not remain compatible between versions.
* No guarantees of API or ABI stability are provided.
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
* When the standardized version of an experimental feature is implemented,
[libcxx] Slightly improved policy for handling experimental features Summary: Following the discussion on the libcxx-dev mailing list (http://lists.llvm.org/pipermail/libcxx-dev/2019-May/000358.html), this implements the new policy for handling experimental features and their deprecation. We basically add a deprecation warning for std::experimental::filesystem, and we remove a bunch of <experimental/*> headers that were now empty. Reviewers: mclow.lists, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits, jfb Tags: #libc Differential Revision: https://reviews.llvm.org/D62428 llvm-svn: 363072
2019-06-11 22:48:40 +08:00
the experimental feature is removed two releases after the non-experimental
version has shipped. The full policy is explained :ref:`here <experimental features>`.
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
Using libc++ when it is not the system default
==============================================
On systems where libc++ is provided but is not the default, Clang provides a flag
called ``-stdlib=`` that can be used to decide which standard library is used.
Using ``-stdlib=libc++`` will select libc++:
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
.. code-block:: bash
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
$ clang++ -stdlib=libc++ test.cpp
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++] Revert OpenBSD-related changes to the documentation This commit partially reverts 0954e2b2d038 and 3fa4cff97480, which make changes to the libc++ documentation implifying that OpenBSD is supported. Neither of these changes have been reviewed AFAICT, so I'm reverting as a matter of enforcing: 1. That changes get reviewed before being committed 2. That we have a discussion and a support plan for supporting OpenBSD officially in libc++ Please note that I would be thrilled to support OpenBSD officially in libc++, however doing so requires more than adding a note in the docs. In particular, please make sure you read the note in [1] about setting up CI testing for OpenBSD. [1]: https://libcxx.llvm.org/#platform-and-compiler-support Differential Revision: https://reviews.llvm.org/D109373
2021-09-08 00:55:48 +08:00
On systems where libc++ is the library in use by default such as macOS and FreeBSD,
this flag is not required.
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
.. _alternate libcxx:
Using a custom built libc++
===========================
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
Most compilers provide a way to disable the default behavior for finding the
standard library and to override it with custom paths. With Clang, this can
be done with:
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
.. code-block:: bash
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
$ clang++ -nostdinc++ -nostdlib++ \
-isystem <install>/include/c++/v1 \
-L <install>/lib \
-Wl,-rpath,<install>/lib \
-lc++ \
test.cpp
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
The option ``-Wl,-rpath,<install>/lib`` adds a runtime library search path,
which causes the system's dynamic linker to look for libc++ in ``<install>/lib``
whenever the program is loaded.
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
GCC does not support the ``-nostdlib++`` flag, so one must use ``-nodefaultlibs``
instead. Since that removes all the standard system libraries and not just libc++,
the system libraries must be re-added manually. For example:
[libcxx] Add new Sphinx documentation Summary: This patch adds Sphinx based documentation to libc++. The goal is to make it easier to write documentation for libc++ since writing new documentation in HTML is cumbersome. This patch rewrites the main page for libc++ along with the instructions for using, building and testing libc++. The built documentation can be found and reviewed here: http://efcs.ca/libcxx-docs In order to build the sphinx documentation you need to specify the cmake options `-DLLVM_ENABLE_SPHINX=ON -DLIBCXX_INCLUDE_DOCS=ON`. This will add the makefile rule `docs-libcxx-html`. Reviewers: chandlerc, mclow.lists, danalbert, jroelofs Subscribers: silvas, cfe-commits Differential Revision: http://reviews.llvm.org/D12129 llvm-svn: 245788
2015-08-23 03:40:49 +08:00
.. code-block:: bash
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
$ g++ -nostdinc++ -nodefaultlibs \
-isystem <install>/include/c++/v1 \
-L <install>/lib \
-Wl,-rpath,<install>/lib \
-lc++ -lc++abi -lm -lc -lgcc_s -lgcc \
test.cpp
Add link to 3rd party GDB pretty-printers llvm-svn: 258270
2016-01-20 09:26:30 +08:00
GDB Pretty printers for libc++
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
==============================
Add link to 3rd party GDB pretty-printers llvm-svn: 258270
2016-01-20 09:26:30 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
GDB does not support pretty-printing of libc++ symbols by default. However, libc++ does
provide pretty-printers itself. Those can be used as:
Add link to 3rd party GDB pretty-printers llvm-svn: 258270
2016-01-20 09:26:30 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
.. code-block:: bash
Add link to 3rd party GDB pretty-printers llvm-svn: 258270
2016-01-20 09:26:30 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
$ gdb -ex "source <libcxx>/utils/gdb/libcxx/printers.py" \
-ex "python register_libcxx_printer_loader()" \
<args>
Add docs for use-configurable libc++ features llvm-svn: 286784
2016-11-14 07:00:30 +08:00
Libc++ Configuration Macros
===========================
Libc++ provides a number of configuration macros which can be used to enable
or disable extended libc++ behavior, including enabling "debug mode" or
thread safety annotations.
**_LIBCPP_DEBUG**:
Implement a throwing version of _LIBCPP_ASSERT. 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
2016-12-28 12:58:52 +08:00
See :ref:`using-debug-mode` for more information.
Add docs for use-configurable libc++ features llvm-svn: 286784
2016-11-14 07:00:30 +08:00
**_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS**:
This macro is used to enable -Wthread-safety annotations on libc++'s
[NFC] Fixed Typos Reviewed By: xgupta Differential Revision: https://reviews.llvm.org/D100705
2021-04-17 23:04:06 +08:00
``std::mutex`` and ``std::lock_guard``. By default, these annotations are
Add docs for use-configurable libc++ features llvm-svn: 286784
2016-11-14 07:00:30 +08:00
disabled and must be manually enabled by the user.
[libc++] Add _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS 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
2016-12-06 03:40:12 +08:00
**_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS**:
This macro is used to disable all visibility annotations inside libc++.
Defining this macro and then building libc++ with hidden visibility gives a
build of libc++ which does not export any symbols, which can be useful when
building statically for inclusion into another library.
Fix PR27374 - Remove the implicit reduced-arity-extension in tuple. 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
2016-12-09 07:57:08 +08:00
[libc++] Add _LIBCPP_DISABLE_EXTERN_TEMPLATE config option 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
2017-04-14 04:13:32 +08:00
**_LIBCPP_DISABLE_EXTERN_TEMPLATE**:
This macro is used to disable extern template declarations in the libc++
headers. The intended use case is for clients who wish to use the libc++
headers without taking a dependency on the libc++ library itself.
Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros. 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
2017-01-14 06:02:08 +08:00
**_LIBCPP_DISABLE_ADDITIONAL_DIAGNOSTICS**:
This macro disables the additional diagnostics generated by libc++ using the
`diagnose_if` attribute. These additional diagnostics include checks for:
[libc++] Improve diagnostics for non-const comparators and hashers in associative containers Summary: When providing a non-const-callable comparator in a map or set, the warning diagnostic does not include the point of instantiation of the container that triggered the warning, which makes it difficult to track down the problem. This commit improves the diagnostic by placing it directly in the body of the associative container. The same change is applied to unordered associative containers, which had a similar problem. Finally, this commit cleans up the forward declarations of several map and unordered_map helpers, which are not needed anymore. <rdar://problem/41370747> Reviewers: EricWF, mclow.lists Subscribers: christof, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D48955 llvm-svn: 348529
2018-12-07 05:46:17 +08:00
* Giving `set`, `map`, `multiset`, `multimap` and their `unordered_`
counterparts a comparator which is not const callable.
* Giving an unordered associative container a hasher that is not const
callable.
Add _LIBCPP_DIAGNOSE_WARNING and _LIBCPP_DIAGNOSE_ERROR macros. 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
2017-01-14 06:02:08 +08:00
[libc++] Support Microsoft ABI without vcruntime headers 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
2017-10-10 03:25:17 +08:00
**_LIBCPP_NO_VCRUNTIME**:
Microsoft's C and C++ headers are fairly entangled, and some of their C++
headers are fairly hard to avoid. In particular, `vcruntime_new.h` gets pulled
in from a lot of other headers and provides definitions which clash with
libc++ headers, such as `nothrow_t` (note that `nothrow_t` is a struct, so
there's no way for libc++ to provide a compatible definition, since you can't
have multiple definitions).
By default, libc++ solves this problem by deferring to Microsoft's vcruntime
headers where needed. However, it may be undesirable to depend on vcruntime
headers, since they may not always be available in cross-compilation setups,
or they may clash with other headers. The `_LIBCPP_NO_VCRUNTIME` macro
prevents libc++ from depending on vcruntime headers. Consequently, it also
prevents libc++ headers from being interoperable with vcruntime headers (from
the aforementioned clashes), so users of this macro are promising to not
attempt to combine libc++ headers with the problematic vcruntime headers. This
macro also currently prevents certain `operator new`/`operator delete`
replacement scenarios from working, e.g. replacing `operator new` and
expecting a non-replaced `operator new[]` to call the replaced `operator new`.
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
**_LIBCPP_ENABLE_NODISCARD**:
Allow the library to add ``[[nodiscard]]`` attributes to entities not specified
as ``[[nodiscard]]`` by the current language dialect. This includes
backporting applications of ``[[nodiscard]]`` from newer dialects and
additional extended applications at the discretion of the library. All
additional applications of ``[[nodiscard]]`` are disabled by default.
See :ref:`Extended Applications of [[nodiscard]] <nodiscard extension>` for
more information.
**_LIBCPP_DISABLE_NODISCARD_EXT**:
This macro prevents the library from applying ``[[nodiscard]]`` to entities
purely as an extension. See :ref:`Extended Applications of [[nodiscard]] <nodiscard extension>`
for more information.
[libc++] Enable deprecation warnings by default Summary: In r342843, I added deprecation warnings to some facilities that were deprectated in C++14 and C++17. However, those deprecation warnings were not enabled by default. After discussing this on IRC, we had finally gotten consensus to enable those warnings by default, and I'm getting around to doing that only now. Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits Differential Revision: https://reviews.llvm.org/D58140 llvm-svn: 355961
2019-03-13 04:10:06 +08:00
**_LIBCPP_DISABLE_DEPRECATION_WARNINGS**:
This macro disables warnings when using deprecated components. For example,
using `std::auto_ptr` when compiling in C++11 mode will normally trigger a
warning saying that `std::auto_ptr` is deprecated. If the macro is defined,
no warning will be emitted. By default, this macro is not defined.
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
[libcxx] Remove unexpected handlers in C++17 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
2017-02-17 11:25:08 +08:00
C++17 Specific Configuration Macros
-----------------------------------
**_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES**:
This macro is used to re-enable all the features removed in C++17. The effect
is equivalent to manually defining each macro listed below.
Add doc for _LIBCPP_ENABLE_CXX17_DISABLED_AUTO_PTR and make it work under _LIBCPP_ENABLE_CXX17_REMOVED_FEATURES llvm-svn: 295407
2017-02-17 11:30:25 +08:00
**_LIBCPP_ENABLE_CXX17_REMOVED_AUTO_PTR**:
[libc++] [P0619] Hide not1 and not2 under _LIBCPP_ENABLE_CXX20_REMOVED_NEGATORS. This also provides some of the scaffolding needed by D102992 and D101729, and mops up after D101730 etc. Differential Revision: https://reviews.llvm.org/D103055
2021-05-25 06:36:17 +08:00
This macro is used to re-enable `auto_ptr`.
**_LIBCPP_ENABLE_CXX17_REMOVED_BINDERS**:
This macro is used to re-enable the `binder1st`, `binder2nd`,
`pointer_to_unary_function`, `pointer_to_binary_function`, `mem_fun_t`,
`mem_fun1_t`, `mem_fun_ref_t`, `mem_fun1_ref_t`, `const_mem_fun_t`,
`const_mem_fun1_t`, `const_mem_fun_ref_t`, and `const_mem_fun1_ref_t`
class templates, and the `bind1st`, `bind2nd`, `mem_fun`, `mem_fun_ref`,
and `ptr_fun` functions.
**_LIBCPP_ENABLE_CXX17_REMOVED_RANDOM_SHUFFLE**:
This macro is used to re-enable the `random_shuffle` algorithm.
**_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS**:
This macro is used to re-enable `set_unexpected`, `get_unexpected`, and
`unexpected`.
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
[libc++] Use c++20 instead of c++2a consistently. * The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9). * Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b). That's a preparation step to add c++2b support to libc++. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D93383
2021-01-07 19:29:04 +08:00
C++20 Specific Configuration Macros:
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
------------------------------------
**_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17**:
This macro can be used to disable diagnostics emitted from functions marked
``[[nodiscard]]`` in dialects after C++17. See :ref:`Extended Applications of [[nodiscard]] <nodiscard extension>`
for more information.
[libc++] [P0619] Hide not1 and not2 under _LIBCPP_ENABLE_CXX20_REMOVED_NEGATORS. This also provides some of the scaffolding needed by D102992 and D101729, and mops up after D101730 etc. Differential Revision: https://reviews.llvm.org/D103055
2021-05-25 06:36:17 +08:00
**_LIBCPP_ENABLE_CXX20_REMOVED_FEATURES**:
This macro is used to re-enable all the features removed in C++20. The effect
is equivalent to manually defining each macro listed below.
**_LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS**:
This macro is used to re-enable redundant members of `allocator<T>`,
including `pointer`, `reference`, `rebind`, `address`, `max_size`,
`construct`, `destroy`, and the two-argument overload of `allocate`.
[libc++] [P0619] Add _LIBCPP_ABI_NO_BINDER_BASES and remove binder typedefs in C++20. Differential Revision: https://reviews.llvm.org/D103753
2021-05-26 02:34:18 +08:00
**_LIBCPP_ENABLE_CXX20_REMOVED_BINDER_TYPEDEFS**:
This macro is used to re-enable the `argument_type`, `result_type`,
`first_argument_type`, and `second_argument_type` members of class
templates such as `plus`, `logical_not`, `hash`, and `owner_less`.
[libc++] [P0619] Hide not1 and not2 under _LIBCPP_ENABLE_CXX20_REMOVED_NEGATORS. This also provides some of the scaffolding needed by D102992 and D101729, and mops up after D101730 etc. Differential Revision: https://reviews.llvm.org/D103055
2021-05-25 06:36:17 +08:00
**_LIBCPP_ENABLE_CXX20_REMOVED_NEGATORS**:
This macro is used to re-enable `not1`, `not2`, `unary_negate`,
and `binary_negate`.
**_LIBCPP_ENABLE_CXX20_REMOVED_RAW_STORAGE_ITERATOR**:
This macro is used to re-enable `raw_storage_iterator`.
[libcxx][type_traits] remove `std::is_literal_type` and `std::result_of` for C++20 C++17 deprecated `std::is_literal_type` and `std::result_of`, C++20 removed them. Implements parts of: * P0174R2 'Deprecating Vestigial Library Parts in C++17'. * P0619R4 'Reviewing Deprecated Facilities of C++17 for C++20'. Reviewed By: ldionne, Mordante, Quuxplusone, #libc Differential Revision: https://reviews.llvm.org/D102992
2021-07-03 01:08:36 +08:00
**_LIBCPP_ENABLE_CXX20_REMOVED_TYPE_TRAITS**:
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
This macro is used to re-enable `is_literal_type`, `is_literal_type_v`,
[libcxx][type_traits] remove `std::is_literal_type` and `std::result_of` for C++20 C++17 deprecated `std::is_literal_type` and `std::result_of`, C++20 removed them. Implements parts of: * P0174R2 'Deprecating Vestigial Library Parts in C++17'. * P0619R4 'Reviewing Deprecated Facilities of C++17 for C++20'. Reviewed By: ldionne, Mordante, Quuxplusone, #libc Differential Revision: https://reviews.llvm.org/D102992
2021-07-03 01:08:36 +08:00
`result_of` and `result_of_t`.
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 22:39:01 +08:00
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
Libc++ Extensions
=================
This section documents various extensions provided by libc++, how they're
provided, and any information regarding how to use them.
.. _nodiscard extension:
Extended applications of ``[[nodiscard]]``
------------------------------------------
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.
[libc++] Implement D2351R0 "Mark all library static cast wrappers as [[nodiscard]]" These [[nodiscard]] annotations are added as a conforming extension; it's unclear whether the paper will actually be adopted and make them mandatory, but they do seem like good ideas regardless. https://isocpp.org/files/papers/D2351R0.pdf This patch implements the paper's effect on: - std::to_integer, std::to_underlying - std::forward, std::move, std::move_if_noexcept - std::as_const - std::identity The paper also affects (but libc++ does not yet have an implementation of): - std::bit_cast Differential Revision: https://reviews.llvm.org/D99895
2021-04-06 02:56:03 +08:00
2. Extended applications of ``[[nodiscard]]``, at the library's discretion,
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
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
[libc++] Implement D2351R0 "Mark all library static cast wrappers as [[nodiscard]]" These [[nodiscard]] annotations are added as a conforming extension; it's unclear whether the paper will actually be adopted and make them mandatory, but they do seem like good ideas regardless. https://isocpp.org/files/papers/D2351R0.pdf This patch implements the paper's effect on: - std::to_integer, std::to_underlying - std::forward, std::move, std::move_if_noexcept - std::as_const - std::identity The paper also affects (but libc++ does not yet have an implementation of): - std::bit_cast Differential Revision: https://reviews.llvm.org/D99895
2021-04-06 02:56:03 +08:00
dialect, may be disabled using macros specific to the dialect in which it was
added. For example, ``_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17``.
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
Applications of the second form, which are pure extensions, may be disabled
by defining ``_LIBCPP_DISABLE_NODISCARD_EXT``.
Entities declared with ``_LIBCPP_NODISCARD_EXT``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This section lists all extended applications of ``[[nodiscard]]`` to entities
which no dialect declares as such (See the second form described above).
libcxx: Add _LIBCPP_NODISCARD_EXT to 38 more functions This builds on the work done in r342808 and adds _LIBCPP_NODISCARD_EXT to 37 more functions, namely: adjacent_find, all_of, any_of, binary_search, clamp, count_if, count, equal_range, equal, find_end, find_first_not_of, find_first_of, find_if, find, includes, is_heap_until, is_heap, is_partitioned, is_permutation, is_sorted_until, is_sorted, lexicographical_compare, lower_bound, max_element, max, min_element, min, minmax_element, minmax, mismatch, none_of, remove_if, remove, search_n, search, unique, upper_bound The motivation here is that we noticed that find_if is nodiscard with Visual Studio's standard library, and we deemed that useful (https://crbug.com/948122). https://devblogs.microsoft.com/cppblog/c17-progress-in-vs-2017-15-5-and-15-6/ says "Our criteria for emitting the warning are: discarding the return value is a guaranteed leak [...], discarding the return value is near-guaranteed to be incorrect (e.g. remove()/remove_if()/unique()), or the function is essentially a pure observer (e.g. vector::empty() and std::is_sorted())." so I went through algorithm and tried to apply these criteria. Some of these, like vector::empty() are already nodiscard per C++ standard and didn't need changing. I didn't (yet?) go over std::string::find* methods which should probably have _LIBCPP_NODISCARD_EXT too (but not as part of this change). Differential Revision: https://reviews.llvm.org/D60145 llvm-svn: 357619
2019-04-04 02:13:08 +08:00
* ``adjacent_find``
* ``all_of``
* ``any_of``
* ``binary_search``
* ``clamp``
* ``count_if``
* ``count``
* ``equal_range``
* ``equal``
* ``find_end``
* ``find_first_of``
* ``find_if_not``
* ``find_if``
* ``find``
[libc++] Add _LIBCPP_ENABLE_NODISCARD and _LIBCPP_NODISCARD_EXT to allow 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
2018-09-23 01:54:48 +08:00
* ``get_temporary_buffer``
libcxx: Add _LIBCPP_NODISCARD_EXT to 38 more functions This builds on the work done in r342808 and adds _LIBCPP_NODISCARD_EXT to 37 more functions, namely: adjacent_find, all_of, any_of, binary_search, clamp, count_if, count, equal_range, equal, find_end, find_first_not_of, find_first_of, find_if, find, includes, is_heap_until, is_heap, is_partitioned, is_permutation, is_sorted_until, is_sorted, lexicographical_compare, lower_bound, max_element, max, min_element, min, minmax_element, minmax, mismatch, none_of, remove_if, remove, search_n, search, unique, upper_bound The motivation here is that we noticed that find_if is nodiscard with Visual Studio's standard library, and we deemed that useful (https://crbug.com/948122). https://devblogs.microsoft.com/cppblog/c17-progress-in-vs-2017-15-5-and-15-6/ says "Our criteria for emitting the warning are: discarding the return value is a guaranteed leak [...], discarding the return value is near-guaranteed to be incorrect (e.g. remove()/remove_if()/unique()), or the function is essentially a pure observer (e.g. vector::empty() and std::is_sorted())." so I went through algorithm and tried to apply these criteria. Some of these, like vector::empty() are already nodiscard per C++ standard and didn't need changing. I didn't (yet?) go over std::string::find* methods which should probably have _LIBCPP_NODISCARD_EXT too (but not as part of this change). Differential Revision: https://reviews.llvm.org/D60145 llvm-svn: 357619
2019-04-04 02:13:08 +08:00
* ``includes``
* ``is_heap_until``
* ``is_heap``
* ``is_partitioned``
* ``is_permutation``
* ``is_sorted_until``
* ``is_sorted``
* ``lexicographical_compare``
* ``lower_bound``
* ``max_element``
* ``max``
* ``min_element``
* ``min``
* ``minmax_element``
* ``minmax``
* ``mismatch``
* ``none_of``
* ``remove_if``
* ``remove``
* ``search_n``
* ``search``
* ``unique``
* ``upper_bound``
[libc++] Use [[nodiscard]] for lock_guard, as an extension Summary: D64914 added support for applying [[nodiscard]] to constructors. This commit uses that capability to flag incorrect uses of std::lock_guard where one forgets to actually create a variable for the lock_guard. rdar://45790820 Reviewers: mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, libcxx-commits, Quuxplusone, lebedev.ri Tags: #libc Differential Revision: https://reviews.llvm.org/D65900 llvm-svn: 368664
2019-08-13 19:12:28 +08:00
* ``lock_guard``'s constructors
[libc++] Implement D2351R0 "Mark all library static cast wrappers as [[nodiscard]]" These [[nodiscard]] annotations are added as a conforming extension; it's unclear whether the paper will actually be adopted and make them mandatory, but they do seem like good ideas regardless. https://isocpp.org/files/papers/D2351R0.pdf This patch implements the paper's effect on: - std::to_integer, std::to_underlying - std::forward, std::move, std::move_if_noexcept - std::as_const - std::identity The paper also affects (but libc++ does not yet have an implementation of): - std::bit_cast Differential Revision: https://reviews.llvm.org/D99895
2021-04-06 02:56:03 +08:00
* ``as_const``
[libc++] Implement C++20's P0476R2: std::bit_cast Thanks to Arthur O'Dwyer for fixing up some of the tests. Differential Revision: https://reviews.llvm.org/D75960
2020-05-29 02:28:38 +08:00
* ``bit_cast``
[libc++] Implement D2351R0 "Mark all library static cast wrappers as [[nodiscard]]" These [[nodiscard]] annotations are added as a conforming extension; it's unclear whether the paper will actually be adopted and make them mandatory, but they do seem like good ideas regardless. https://isocpp.org/files/papers/D2351R0.pdf This patch implements the paper's effect on: - std::to_integer, std::to_underlying - std::forward, std::move, std::move_if_noexcept - std::as_const - std::identity The paper also affects (but libc++ does not yet have an implementation of): - std::bit_cast Differential Revision: https://reviews.llvm.org/D99895
2021-04-06 02:56:03 +08:00
* ``forward``
* ``move``
* ``move_if_noexcept``
* ``identity::operator()``
* ``to_integer``
* ``to_underlying``