[Clang] Ignore -fchar8_t in C

[cor3ntin]

In C, char8_t is an alias to unsigned char, and should never be a keyword.

Fixes #55373

[llvmbot]

@llvm/pr-subscribers-clang

Author: cor3ntin (cor3ntin)

Changes

In C, char8_t is an alias to unsigned char, and should never be a keyword.

Fixes #55373

---

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

3 Files Affected:

• (modified) clang/docs/ReleaseNotes.rst (+2)
• (modified) clang/include/clang/Driver/Options.td (+2-1)
• (modified) clang/test/Lexer/char8_t.cpp (+1)

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 203958dab7430..2839ad81a8149 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -317,6 +317,8 @@ Modified Compiler Flags
 
 - The ``-mexecute-only`` and ``-mpure-code`` flags are now accepted for AArch64 targets. (#GH125688)
 
+- The ``-fchar8_t`` flag is no longer consider in non-C++ languages modes. (#GH55373)
+
 Removed Compiler Flags
 -------------------------
 
diff --git a/clang/include/clang/Driver/Options.td b/clang/include/clang/Driver/Options.td
index 11677626dbf1f..d55d15750f443 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -3879,7 +3879,8 @@ defm char8__t : BoolFOption<"char8_t",
   LangOpts<"Char8">, Default<cpp20.KeyPath>,
   PosFlag<SetTrue, [], [ClangOption], "Enable">,
   NegFlag<SetFalse, [], [ClangOption], "Disable">,
-  BothFlags<[], [ClangOption, CC1Option], " C++ builtin type char8_t">>;
+  BothFlags<[], [ClangOption, CC1Option], " C++ builtin type char8_t">>,
+  ShouldParseIf<cplusplus.KeyPath>;
 def fshort_wchar : Flag<["-"], "fshort-wchar">, Group<f_Group>,
   HelpText<"Force wchar_t to be a short unsigned int">;
 def fno_short_wchar : Flag<["-"], "fno-short-wchar">, Group<f_Group>,
diff --git a/clang/test/Lexer/char8_t.cpp b/clang/test/Lexer/char8_t.cpp
index d65597c68d8bc..2148609155186 100644
--- a/clang/test/Lexer/char8_t.cpp
+++ b/clang/test/Lexer/char8_t.cpp
@@ -5,6 +5,7 @@
 // RUN: %clang_cc1 -std=c++17 -verify %s
 // RUN: %clang_cc1 -std=c++17 -verify %s -fno-char8_t
 // RUN: %clang_cc1 -std=c++20 -verify %s -fno-char8_t
+// RUN: %clang_cc1 -x c -verify %s -fchar8_t
 
 #if defined(__cpp_char8_t) != defined(CHAR8_T)
 #error wrong setting for __cpp_char_t

[AaronBallman]

Am I correct in understanding that the issue here is with passing -fchar8_t and then including uchar.h in a conforming C23 standard library? (Otherwise, this does seem like it removes useful functionality for people who want to opt into improved type safety in C.)

[cor3ntin]

This is part of the problem, yes.
we also do not support char16_t/char32_t as keywords in C and u8 behaves differently.
And of course, there is no way to use it with the standard library or... any library?

Moreover we have 0 tests for C so I don't think we can claim to support that as an extension even if we wanted to. It would take significantly more effort than having a flag.

Afaict the support was purely accidental

[AaronBallman]

Thank you for the explanation, that makes sense

[AaronBallman]

Suggested change

	- The ``-fchar8_t`` flag is no longer consider in non-C++ languages modes. (#GH55373)
	- The ``-fchar8_t`` flag is now diagnosed in non-C++ languages modes. (#GH55373)

[AaronBallman]

Shouldn't this generate a diagnostic now? Or are we planning to continue to accept in cc1 mode? If so, we need a driver test showing we reject from the driver side.

[cor3ntin]

ShouldParseIf seems never to diagnose. I wanted to ask you about that because it might be surprising
https://godbolt.org/z/6oaPfoWPj

[AaronBallman]

CC @jansvoboda11 @MaskRay for more opinions as driver and options maintainers.

I guess I find that behavior kind of surprising. I would expect "you passed this flag and this flag does nothing" should at least be a warning. It's a bit different from an unknown flag, but the same general logic applies: the user passed something and we either know about it and explicitly don't do anything with it, or we don't know about it and don't do anything with it, but either way it seems like the user should be told "this was unknown".

[cor3ntin]

I agree, but I think it's preexisting / orthogonal

[AaronBallman]

Yup, it is! Only action item I expect out of that is filing an issue if the options folks agree.

[jansvoboda11]

Filing an issues sounds good to me. I don't think great diagnostics for -cc1 flags are a high priority, but improving them certainly doesn't hurt!

[MaskRay]

If we want to emit a warning, in RenderCharacterOptions, we cannot unconditionally claim the Arg, but only claim it when the language mode is C++. I have some notes: https://maskray.me/blog/2023-08-25-clang-wunused-command-line-argument

[cor3ntin]

#139058

[AaronBallman]

LGTM