The documentation CI job is very cheap, so we can afford to keep it
around even with reduced capacity. This commit fixes the documentation
(which had an invalid reference in it) and re-enables that CI step.
Differential Revision: https://reviews.llvm.org/D116897
Although we moved to Github Issues. The bug report message refers to
Bugzilla still. This patch tries to update these URLs.
Reviewed By: MaskRay, Quuxplusone, jhenderson, libunwind, libc++
Differential Revision: https://reviews.llvm.org/D116351
Mention support for MinGW in the docs. Rename the existing windows
CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much
"Windows", just different toolchain environments.
Add an XFAIL for a recently added test that fails in the MinGW DLL
configuration (with an explanation of what's causing the failure).
Differential Revision: https://reviews.llvm.org/D112215
This effort is dedicated to deflake the tests of the users which depend
on the unspecified behavior of algorithms and containers. This also
might help updating the sorting algorithm in libcxx which has the
quadratic worst case in the future or at least create a new one under
flag.
For detailed design, please see the design doc I provide in the patch.
Differential Revision: https://reviews.llvm.org/D96946
This changes adds the pipeline config for both 32-bit and 64-bit AIX targets. As well, we add a lit feature `LIBCXX-AIX-FIXME` which is used to mark the failing tests which remain to be investigated on AIX, so that the CI produces a clean build.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D111359
Per our support plan we should now support Clang 12 and 13. Adjust the
documentation and the CI runners. The change indirectly moves the main
CI runners to use the Clang 14 nightly builds.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D112360
This commit partially reverts 0954e2b2d0 and 3fa4cff974, 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
Add issue tracking and assignment for the implementation of P1614R2: The Mothership has Landed.
Reviewed By: cjdb, #libc, Mordante, Quuxplusone
Differential Revision: https://reviews.llvm.org/D107877
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.
The various design docs have been moved to RST, and the linked blog post
does not apply anymore since libc++ is the default library used by Clang
on Apple platforms.
This commit finishes moving the <atomic> design documents to the RST
documentation and removes the old documentation. https://libcxx.llvm.org
is already pointing to the new documentation only now, so the removal of
the old documentation is really a NFC.
I went over the old documentation and I don't think we're leaving anything
important behind - I think everything important was mentionned in the RST
documentation anyway.
A status page for libc++'s Format library. The page is inspired by
@zoecarver's Ranges status page.
Differential Revision: https://reviews.llvm.org/D101085
The added documents have two tables: 1 containing links to issues and papers related to ranges. And the other contains most of the sections from the One Ranges Proposal, with their dependencies linked. This will allow us to assign work that can be done in parallel.
Differential Revision: https://reviews.llvm.org/D100393
Adds documentation around libc++'s policy to add noexcept to things that cannot throw but aren't marked as noexcept.
Refs LWG 3518 and D95251.
Differential Revision: https://reviews.llvm.org/D95821
Also:
* Fix header line in all status tables.
* Use C++20 instead of C++2a.
Reviewed By: ldionne, #libc, miscco
Differential Revision: https://reviews.llvm.org/D92306
Also, add notes about exporting ABI symbols.
Later, we can add notes about using git-clang-format before sending a patch for review.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D92300
Currently, papers and issues are in separate .csv files (that is easier to update), but I can put them inline.Transforming current html tables into rst are done by the script (attached to the patch FYI but I'll remove it before committing).
I'll of course update RST files before committing to match any modifications that may happen in master branch.
This patch moves the status pages in www/ to RST format in docs/.
It also does some other minor changes: fix copyright year and broken comment end, adds substitutions for coherence (and add colors, but that can be removed easily).
It adds as well redirects from old to new status pages.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D92076
This increases the Mac OS requirement for building libc++ to 10.12.
Note that it doesn't change whether the *headers* still support older
platforms -- it's only that macOS >= 10.12 is required to build the
dylib from sources.
Differential Revision: https://reviews.llvm.org/D74489
It's hard to imagine someone using a recent version of libc++ with a
roughly 3 years old Clang. Since we're not testing libc++ with Clang 3.5
anyway, claiming support for it is somewhat of a lie.
Note that we don't test Clang 4 either, however I have no reason to bump
the requirement beyond Clang 4 at the moment, whereas removing Clang 3.5
allows simplifying the test suite.
Differential Revision: https://reviews.llvm.org/D76618
Summary:
This patch make G++03 explicitly unsupported with libc++, as discussed on the mailing lists.
Below is the rational for this decision.
----------------------------------------------------------------------------------------------------
libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users.
Our C++03 users are all using Clang. They must be. Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.
Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could::
* Improve Correctness:
Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics.
* Achieve ABI stability between C++03 and C++11
Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed.
* Decrease Compile Times and Memory Usage:
Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially.
* Decrease Binary Size
Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne, EricWF
Subscribers: zoecarver, aprantl, dexonsmith, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D63154
llvm-svn: 363219
As we gear up to drop support for GCC in C++03, we should make clear
what our C++03 mode is, the C++11 extensions it provides,
and the C++11 extensions it depends on.
The section of this document discussing user-facing extensions has
been left blank while the community discusses new directions. For now
it's just a warning to users.
Additionally, the document contains examples of how these extensions
should be used and why. For example, using alias templates over class
templates.
llvm-svn: 363110
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
Summary:
This updates all places in documentation that refer to "Mac OS X", "OS X", etc.
to instead use the modern name "macOS" when no specific version number is
mentioned.
If a specific version is mentioned, this attempts to use the OS name at the time
of that version:
* Mac OS X for 10.0 - 10.7
* OS X for 10.8 - 10.11
* macOS for 10.12 - present
Reviewers: JDevlieghere
Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits
Tags: #clang, #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D62654
llvm-svn: 362113
Summary:
This change allows specifying the version of libc++abi's ABI to re-export
when configuring CMake. It also clearly identifies which ABI version of
libc++abi each export file contains.
Finally, it removes hardcoded knowledge about the 10.9 SDK for MacOS,
since that knowledge is not relevant anymore. Indeed, libc++ can't be
built with the toolchain that came with the 10.9 SDK anyway because
the version of Clang it includes is too old (for example if you want
to build a working libc++.dylib, you need bugfixes to visibility
attributes that are only in recent Clangs).
Reviewers: dexonsmith, EricWF
Subscribers: mgorny, christof, jkorous, arphaman, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59489
llvm-svn: 356587
This fixes most references to the paths:
llvm.org/svn/
llvm.org/git/
llvm.org/viewvc/
github.com/llvm-mirror/
github.com/llvm-project/
reviews.llvm.org/diffusion/
to instead point to https://github.com/llvm/llvm-project.
This is *not* a trivial substitution, because additionally, all the
checkout instructions had to be migrated to instruct users on how to
use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of
checking out various projects into various subdirectories.
I've attempted to not change any scripts here, only documentation. The
scripts will have to be addressed separately.
Additionally, I've deleted one document which appeared to be outdated
and unneeded:
lldb/docs/building-with-debug-llvm.txt
Differential Revision: https://reviews.llvm.org/D57330
llvm-svn: 352514
Summary:
This patch implements all the feature test macros libc++ currently supports, as specified by the standard or cppreference prior to C++2a.
The tests and `<version>` header are generated using a script. The script contains a table of each feature test macro, the headers it should be accessible from, and its values of each dialect of C++.
When a new feature test macro is added or needed, the table should be updated and the script re-run.
Reviewers: mclow.lists, jfb, serge-sans-paille
Reviewed By: mclow.lists
Subscribers: arphaman, jfb, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56750
llvm-svn: 351286
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
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++ 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
Nikolas Klauser