[clang] [BitInt] Expose a _BitInt literal suffix in C++ (PR #86586)

[Aaron Ballman via cfe-commits]

================
@@ -1127,9 +1148,9 @@ NumericLiteralParser::NumericLiteralParser(StringRef TokSpelling,
       // wb and WB are allowed, but a mixture of cases like Wb or wB is not. We
       // explicitly do not support the suffix in C++ as an extension because a
       // library-based UDL that resolves to a library type may be more
-      // appropriate there.
-      if (!LangOpts.CPlusPlus && ((s[0] == 'w' && s[1] == 'b') ||
-          (s[0] == 'W' && s[1] == 'B'))) {
+      // appropriate there. The same rules apply for __wb/__WB.
+      if ((!LangOpts.CPlusPlus || PossibleBitInt) &&
+          ((s[0] == 'w' && s[1] == 'b') || (s[0] == 'W' && s[1] == 'B'))) {
----------------
AaronBallman wrote:

I looked through the lexer and we might be okay here for normal lexing uses. When we lex, we grab all adjacent characters and digits:

https://github.com/llvm/llvm-project/blob/d3bc9cc99b3d45e1fb8d65a57e308e899439fe26/clang/lib/Lex/Lexer.cpp#L2035
https://github.com/llvm/llvm-project/blob/d3bc9cc99b3d45e1fb8d65a57e308e899439fe26/clang/include/clang/Basic/CharInfo.h#L169

So for a complete (ill-formed) TU like `#if 1w`, we get `1w\0` in the numeric literal parser. But if we lex a string that isn't null terminated for some reason, we'd have the overrun.

CC @cor3ntin @tahonermann for opinions on what we should do here, if anything. However, because this is existing behavior, I'd say let's move forward with your patch without changing this yet.

https://github.com/llvm/llvm-project/pull/86586