[libc] build fix: always use our char8_t headers even in overlay mode

[uzairnawaz]

Build fix caused by certain platforms not providing char8_t when expected
Temporary fix to just always use our own definition, even in overlay mode.

[llvmbot]

@llvm/pr-subscribers-libc

Author: Uzair Nawaz (uzairnawaz)

Changes

Build fix caused by certain platforms not providing char8_t when expected
Temporary fix to just always use our own definition, even in overlay mode.

---

Full diff: https://github.com/llvm/llvm-project/pull/144433.diff

2 Files Affected:

• (modified) libc/hdr/types/char8_t.h (-8)
• (modified) libc/src/__support/wchar/character_converter.cpp (+1-1)

diff --git a/libc/hdr/types/char8_t.h b/libc/hdr/types/char8_t.h
index 31de764658f9e..4d71e3dd89098 100644
--- a/libc/hdr/types/char8_t.h
+++ b/libc/hdr/types/char8_t.h
@@ -9,14 +9,6 @@
 #ifndef LLVM_LIBC_HDR_TYPES_CHAR8_T_H
 #define LLVM_LIBC_HDR_TYPES_CHAR8_T_H
 
-#ifdef LIBC_FULL_BUILD
-
 #include "include/llvm-libc-types/char8_t.h"
 
-#else // overlay mode
-
-#include "hdr/uchar_overlay.h"
-
-#endif // LLVM_LIBC_FULL_BUILD
-
 #endif // LLVM_LIBC_HDR_TYPES_CHAR8_T_H
diff --git a/libc/src/__support/wchar/character_converter.cpp b/libc/src/__support/wchar/character_converter.cpp
index bac2f6d827e13..ef5730a70a033 100644
--- a/libc/src/__support/wchar/character_converter.cpp
+++ b/libc/src/__support/wchar/character_converter.cpp
@@ -71,7 +71,7 @@ ErrorOr<char8_t> CharacterConverter::pop_utf8() {
 
   // Shift to get the next 6 bits from the utf32 encoding
   const char32_t shift_amount =
-      (state->total_bytes - state->bytes_processed - 1) * ENCODED_BITS_PER_UTF8;
+      static_cast<char32_t>((state->total_bytes - state->bytes_processed - 1) * ENCODED_BITS_PER_UTF8);
   if (state->bytes_processed == 0) {
     /*
       Choose the correct set of most significant bits to encode the length

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[lntue]

It is better to explicitly mention and exclude such targets.

[michaelrj-google]

the issue isn't actually the targets, it's that the glibc headers only define char8_t under specific circumstances (C23 or higher), which makes them unreliable for defining this type. I think the reason it works on other targets is the default C++ version is new enough that it defines char8_t as a keyword.

[michaelrj-google]

Tested on aarch64 and x86_64, passed on both.