Consistent with glibc headers, where `noexcept` is used in C++
(or `throw()` in older C++ which llvm-libc doesn't support) in
the public function declarations, `__attribute__((__nothrow__))` is
used in C for compilers that support it.
commit a9aff440d9dd ("[libc][docs] reorganize documentation (#118836)")
moved https://libc.llvm.org/math/index.html to
https://libc.llvm.org/headers/math/index.html which makes links from
various slide decks stale.
There's an extension for sphinx that can generate redirects. Add a dependency
on that, then use it to create a redirect so that those older links still work.
I was able to install this sphinx extension via:
$ sudo apt install python3-sphinx-reredirects
We may need to install this on whatever server generates the llvm
documentation.
Summary:
This installs the shared header to the users installation. I couldn't
decide if this should be a standalone thing or use the existing support
in `include/` mostly because this is completely separate from hdrgen
stuff and it's C++.
Creates a new toctree "Support" under which we have distinct links to arch,
platform, and compiler support.
* Moved "Platform Support" from index landing page to new doc.
* Created explicit "Architecture Support". Requested in https://github.com/llvm/llvm-project/issues/118964#issuecomment-2531503046.
* Moved "Compiler Support" from Status toctree to new Support toctree.
---------
Co-authored-by: Carlo Cabrera <github@carlo.cab>
FreeListHeap uses the _end symbol which conflicts with the _end symbol
defined by GPU start.cpp files so for now we exclude the test and the
fuzzer on GPU.
- Replace section on ABI Compatibility with a rephrased warning at the
top of
the page.
- Add links to the Note.
- Update C and POSIX standards.
- Inline link to fuzzing.
Summary:
In order for this to work with CUDA we need to declare functions as
__host__ and __device__ while also making sure we only call the GPU
functions during the CUDA / HIP compile stage.
Summary:
This is installed unconditionally because of the dependency in the
`hdr/` directory. Remove this so it's only used on the systems that need
it.
Usually posix functions have individual doc pages, and each header has its own
list of required macro definitions. Use a simpler key of "in-latest-posix" to
signal that the URL convention can be followed.
Add support for a "removed-in-posix-2008" key which will link to the 2004 docs
for functions like bcmp, bcopy, bzero, index, and rindex from strings.h.
I don't want to add all of these links for pthreads.h, so automating this will
make documenting these go much faster.
Building with the source directory rooted in the libc subdirectory isn't
tested in CI and can lead to subtle build problems (cf. #118871).
Let's fail fast with a helpful error message instead to help users
configure libc correctly.
Co-authored-by: Nick Desaulniers <nickdesaulniers@users.noreply.github.com>
bcmp, bcopy, and bzero should be moved from libc/src/string/ to
lib/src/strings/ in order for docgen to use existing conventions to find
whether we implement a function or not.
We should add support to docgen for mentioning glibc extensions (mempcpy) or
extensions from other libcs.
so that docgen can find our definitions.
Also eliminate the enums. POSIX is careful to call these "symbolic constants"
rather than specifically whether they are preprocessor macro defines or not.
Enums are useful to expressing mutual exclusion when the enum values are in
distinct enums which can improve type safety. Our enum values weren't using
that pattern though; they were all in one big anonymous enum.
Link:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/pthread.h.htmlFixes: #88997
docgen relies on the convention that we have a file foo.cpp in
libc/src/\<header\>/. Because the above functions weren't in libc/src/strings/
but rather libc/src/string/, docgen could not find that we had implemented
these.
Rather than add special carve outs to docgen, let's fix up our sources for
these 7 functions to stick with the existing conventions the rest of the
codebase follows.
Link: #118860Fixes: #118875
For whatever reason, each ctype test contains its own copy of
some identical helper source code. These local helpers were
defined with external linkage for no apparent reason. This leads
to multiple definition errors when linking these tests together.
This change moves each file's local helper code into an anonymous
namespace so it has internal linkage. It's notable that the libc
test code does not follow the most common norm of gtest-style
code where all the `TEST(...)` cases themselves are defined
inside an anonymous namespace (along with whatever other local
helpers they use); whether libc's tests should follow that usual
convention can be addressed holistically in future discussion.
The replacement of numerous cut&paste'd copies of identical
helper code with sharing the source code in some usual fashion is
also left for later cleanup.
This change only makes the test code not straightforwardly have
multiple definition errors that prevent linking a test executable
at all.
The a0c4f854cad2b97e44a1b58dc1fd982e1c4d60f3 change replaced the
local int_to_b36_char function returning `char` with uses of the
__support function of the same name that returns `int`. The uses
of the old local function lacked the casts that all other uses of
the shared function of the same name had. Add them.
It seems that LIBC_TARGET_OS_IS_MACOS and LIBC_TARGET_OS_IS_IPHONE were
never actually used in the code, so these definitions can be removed.
I came across these because libc++ now depends on llvm-libc to build
(for from_chars), and the unguarded use of TargetConditionals.h broke
some of our downstream configurations. There are some platforms for
which `__APPLE__` is defined but that don't provide TargetConditionals.h.
If there is a need to keep defining those, the compiler also provides
some uglier macro definitions like __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
that do not require including any header.
