Bazel only supports overlay build currently, so there's always system
libc (and system errno_ present. Use the new
LIBC_ERRNO_MODE_SYSTEM_INLINE by default, instead of using thread-local
one in the unit tests and system errno for "public packaging" (i.e. prod
build). This way, we can ensure that we're testing the same
configuration as the one that will be used in production.
This is the second attempt to do that after f9146cc was reverted in
279e82f. Since then, many tests have been migrated to ErrnoCheckingTest
so the change should be safe even for those downstream customers that
clobber system errno value before unit tests are being called.
This would ensure that errno value is cleared out before test execution
and tests pass even when LIBC_ERRNO_MODE_SYSTEM_INLINE is specified (and
errno may be clobbered before test execution).
A lot of the tests would fail, however, since errno would end up getting
set to EDOM or ERANGE during test execution and never validated before
the end of the test. This should be fixed - and errno should be
explicitly checked or ignored in all of those cases, but for now add a
TODO to address it later (see open issue #135320) and clear out errno in
test fixture to avoid test failures.
I'm not sure how libc should be configuring this in bazel, but for now
it seems like `LIBC_THREAD_MODE_PLATFORM` restores the default behavior.
Defining this param is required:
```
ERROR: /var/lib/buildkite-agent/.cache/bazel/_bazel_buildkite-agent/c9d34ded3a9d94cc250207948aceadfc/external/llvm-project/libc/BUILD.bazel:5788:14: Compiling libc/src/stdio/generic/vprintf.cpp failed: (Exit 1): clang failed: error executing CppCompile command (from target @@llvm-project//libc:vprintf) /usr/lib/llvm-18/bin/clang -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object -fcolor-diagnostics -fno-omit-frame-pointer ... (remaining 31 arguments skipped)
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from external/llvm-project/libc/src/stdio/generic/vprintf.cpp:11:
In file included from external/llvm-project/libc/src/__support/File/file.h:19:
external/llvm-project/libc/src/__support/threads/mutex.h:25:2: error: LIBC_THREAD_MODE is undefined
25 | #error LIBC_THREAD_MODE is undefined
| ^
```
As an alternative to this PR, we could make the libc header default to
`LIBC_THREAD_MODE_PLATFORM` if not provided, instead of an `#error`
We already use cc rules from `@rules_cc//cc:defs.bzl` in a few files,
but this uses it everywhere. Done automatically by running `buildifier
--lint=fix
--warnings=native-cc-binary,native-cc-library,native-cc-test,load` over
all the files. I also ran `buildifier` once more to ensure there wasn't
any missing formatting, so that caused a few unrelated diffs.
This adds two dependencies that I wanted to be part of #151090 but
forgot to add them before the last push, which related to `wcschr.cpp`
and were originally broken by #150661.
Signed-off-by: Ingo Müller <ingomueller@google.com>
This was broken by #150661, which added includes to `wcspbrk.cpp` and
`wcschr.cpp` that weren't in the dependencies of the corresponding
targets.
Signed-off-by: Ingo Müller <ingomueller@google.com>
This target was marked as Linux-only in
51a4ab287f43c129dd531867be880480a85ecb1e to make "bazel build
@llvm-project//libc/..." clean (which it still is).
There's nothing Linux-specific about this header library, we just use
"target_incompatible_with" clause here to ensure that all libc functions
for float128 types won't be built on Mac, in lieu of a better exclusion
mechanism in Bazel.
However, since llvm_libc_types_float128 is now a transitive dependency
of ":libcxx_shared_headers" used for hand-in-hand code sharing with
libc++, we may need to build this target even on platforms that don't
have float128.
Fow now, mark this target Windows-compatible to unlock the downstream
Windows Bazel build of ":libcxx_shared_headers".
See https://bazel.build/docs/bazel-and-cpp#toolchain-features for why
this feature is recommended for C++ projects.
215dbcb2bc5c1b1bc8775db2a7c22f67f3949fd7 added the necessary default
Bazel flag to make this feature functional. It can be enabled on a
per-project basis. Do this now for llvm-libc.
After enabling this feature, Blaze tries to parse headers from all
header-only libraries, even if the headers are not explicitly used in
tests, which allows to detect the issues early on.
Fix a couple of -Wunused-function warnings by marking the static
functions as constexpr or inline.
LIBC_HAS_SANITIZER (which is defined if ASan, MSan, or UBSan is enabled)
is currently used to implicitly disable null checks, normally enabled
via LIBC_ADD_NULL_CHECKS config value. Remove this condition, and rely
purely on the config value instead:
* LIBC_HAS_SANITIZER will be true even for UBSan modes which doesn't
rely on null checks at all (e.g. -fsanitize=alignment)
* null checks today (implemented via __builtin_trap) should function
normally today even when sanitizer is enabled - trap is still a trap
* tests have been migrated to WITH_SIGNAL(-1) which doesn't prescript a
particular signal / exit-code, and thus should pass even if sanitizers
override the default ones.
