Macros starting with alphabetic characters such as "LLVM" are in
the application name space and cannot be defined or used by a
conforming implementation's headers. This fixes the headers that
are entirely generated, and the __llvm-libc-common.h header to
use a conforming macro name for the header guard. That is, it
starts with "_LLVM_LIBC_" instead of "LLVM_LIBC_", as identifiers
starting with an underscore followed by a capital letter are in
the name space reserved for the implementation.
The remaining headers either will be fixed implicitly by removal
of their custom template files, or will need to be fixed by hand.
Relying on features.h is problematic since codebases are free to have
such a header on their search path, which breaks compilation. libc
should instead provide a more standard way of getting __LLVM_LIBC__.
Since __llvm-libc-common.h is included from all libc headers, defining
__LLVM_LIBC__ there ensures that this define is available whenever any
of the standard header is included.
This is to ensure that calls to `setjmp(3)` result in correct code
generation that respects `setjmp(3)`'s `returns_twice` behavior.
Otherwise, we might run into bugs (for example, Clang may perform
tail-call optimization on this function if `-fno-builtins` is set
(#122840)).
---------
Co-authored-by: Nick Desaulniers <nick.desaulniers@gmail.com>
When in modes like C99, the _Noreturn keyword is not available in
C. But GNU-compatible compilers have a `noreturn` attribute with
the same effect on function declarations.
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.
The C99 restrict keyword is spelled __restrict in the libc
headers so it can be parsed by C++ compilers with GNU extensions
that recognize it. When GNU extensions are not available in C++
Towards the goal of getting `ninja libc-lint` back to green, fix the numerous
instances of:
warning: header guard does not follow preferred style [llvm-header-guard]
This is because many of our header guards start with `__LLVM` rather than
`LLVM`.
To filter just these warnings:
$ ninja -k2000 libc-lint 2>&1 | grep llvm-header-guard
To automatically apply fixits:
$ find libc/src libc/include libc/test -name \*.h | \
xargs -n1 -I {} clang-tidy {} -p build/compile_commands.json \
-checks='-*,llvm-header-guard' --fix --quiet
Some manual cleanup is still necessary as headers that were missing header
guards outright will have them inserted before the license block (we prefer
them after).
To improve code generation for C++ code that directly includes our
headers, the external function definitions will now be marked noexcept.
This may not be necessary for the internal definitions since we build
with the -fno-exceptions flag.
Reviewed By: sivachandra
Differential Revision: https://reviews.llvm.org/D141095
With modern architectures having a thread pointer and language supporting
thread locals, there is no reason to use a function intermediary to access
the thread local errno value.
The entrypoint corresponding to errno has been replaced with an object
library as there is no formal entrypoint for errno anymore.
Reviewed By: jeffbailey, michaelrj
Differential Revision: https://reviews.llvm.org/D120920
Only the methods currently required by the libc have been added.
Most of the existing uses of atomic operations have been switched over
to this new class. A future change will clean up the rest of uses.
This change now allows building mutex and condition variable code with a
C++ compiler which does not have stdatomic.h, for example g++.
Reviewed By: lntue
Differential Revision: https://reviews.llvm.org/D120642
Summary:
Made all header files consistent based of this documentation: https://llvm.org/docs/CodingStandards.html#file-headers.
And did the same for all source files top of file comments.
Reviewers: sivachandra, abrachet
Reviewed By: sivachandra, abrachet
Subscribers: MaskRay, tschuett, libc-commits
Tags: #libc-project
Differential Revision: https://reviews.llvm.org/D77533
Summary:
This patch illustrates some of the features like modularity we want
in the new libc. Few other ideas like different kinds of testing, redirectors
etc are not yet present.
Reviewers: dlj, hfinkel, theraven, jfb, alexshap, jdoerfert
Subscribers: mgorny, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67867
llvm-svn: 373764
