Currently there is no tests for generic macros of generated `stdbit.h`
header in C, and it is easy to make typo mistakes as in
https://github.com/llvm/llvm-project/issues/84658. In this patch, we
add a simple test for them in C.
Either:
- I forgot my alphabet (that E comes before F).
- My juvenile inner brain finds unsigned literal constants with the sequence FU
funny.
¿Por qué no los dos?
Summary:
Recent changes added an include path in the float128 type that used the
internal `libc` path to find the macro. This doesn't work once it's
installed because we need to search from the root of the install dir.
This patch adds "include/" to the include path so that our inclusion
of installed headers always match the internal use.
The intent of the test is to check that: 1. The type generic macros are
defined. 2. Those macros dispatch to the correct underlying function.
The issue is that when new functionality is added to our stdbit.h without
rolling out the new entrypoint to all targets, this test breaks because our
generated stdbit.h will not contain declarations for the underlying function.
In that case, we should just declare the underlying functions first before
including our generated stdbit.h which just contains declarations. A definition
is a declaration, but redeclarations must match, hence the additions of
noexcept and extern "C".
Summary:
This test was added to test the generated header. Unfortunately this
doesn't work if the header is never generated. Add a check to make sure
the user has included it in the list of headers.
Summary:
We use `add_libc_test' now because it works for both hermetic and unit
tests. If the test needs to be unit test only you use `UNIT_TEST_ONLY`
as an argument.
This header first appeared in 4.4BSD and is provided by a number of C
libraries including Newlib. Several of our embedded projects use this
header and so to make LLVM libc a drop-in replacement, we need to
provide it as well.
For the initial commit, we only implement singly linked variants (SLIST
and STAILQ). The doubly linked variants (LIST, TAILQ and CIRCLEQ) can be
implemented in the future as needed.
