[libc-commits] [compiler-rt] [lldb] [llvm] [clang-tools-extra] [libc] [libcxx] [clang] [lld] [flang] Fix clang to recognize new C23 modifiers %w and %wf when printing (PR #71771)

[James Y Knight via libc-commits]

================
@@ -484,6 +484,26 @@ bool clang::analyze_format_string::parseFormatStringHasFormattingSpecifiers(
   return false;
 }
 
+ArgType clang::analyze_format_string::wToArgType(
+    int size, bool fast, ASTContext &C) {
+  ArgType fastType = C.getTargetInfo().getTriple().isArch64Bit() ? C.LongLongTy : C.IntTy;
----------------
jyknight wrote:

It's actually quite a mess right now...

We currently have TargetInfo getIntTypeByWidth/getLeastIntTypeByWidth, but, no getFastIntTypeByWidth.

And this is a real problem...e.g. clang's stdint.h builtin-header goes through a ton of complexity to obfuscate that in fact it just ends up defining int_leastN_t and int_fastN_t as aliases to intN_t, on all platforms we support (which have all of 8/16/32/64-bit types available.)

But, clang's stdint.h defers to the libc's stdint.h if that exists, and e.g. on glibc, int_fast{16|32}_t are instead defined as int (32bit) or long (64bit). 

OK, fine...Except -- we ALSO define a bunch of preprocessor macros for the fast types in InitPreprocessor (e.g. `__INT_FAST16_TYPE__`. Which assume that fast == least. And, of course, these don't match the libc stdint.h's definitions...

And then there's the problem of which of 'long' vs 'long long' is used on various platforms, when both are 64-bit types.

I think we need to fix all that as a prerequisite. At that point, this code simply calls getFastIntTypeByWidth.

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