[clang] [RFC][Clang] Enable custom type checking for printf (PR #86801)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> Thanks for the comments @AaronBallman. The core issue here is that the current builtin handling design does not allow multiple overloads for the same identifier to coexist (ref.
> 
> https://github.com/llvm/llvm-project/blob/eacda36c7dd842cb15c0c954eda74b67d0c73814/clang/include/clang/Basic/Builtins.h#L66
> ), unless the builtins are defined in target specific namespaces which is what I tried in my original patch . If we want change this approach, I currently think of couple of ways at a top level
> 
>     1. As you said, we could have OCL specific LibBuiltin and LangBuiltin TableGen classes (and corresponding macros in Buitlins.inc). To make this work they would need new builtin ID's  of different form (say "BI_OCL##identifier"). This is very Language specific.
> 
>     2. Probably change the current Builtin Info structure to allow vector of possible signatures for an identifier. The builtin type decoder could choose the appropriate signature based on LangOpt. (This wording is vague and could be a separate discussion in itself )
> 
> 
> either way, changes in current design are required. printf is the only current use case I know that can benefit out of this (since OpenCL v1.2 s6.9.f says other library functions defined in C standard header are not available ,so 🤷‍♂️ ). But I guess we could have more use cases in future. can this be a separate discussion ? This patch would unblock my current work for now.

I looked at the OpenCL spec for C standard library support and was surprised that 1) it's only talking about C99 so it's unclear what happens for C11 (clause 6 says "This document describes the modifications and restrictions to C99 and C11 in OpenCL C" but 6.11 only talks about C99 headers and leaves `iso646.h`, `math.h`, `stdbool.h`, `stddef.h`, (all in C99) as well as `stdalign.h`, `stdatomic.h`, `stdnoreturn.h`, `threads.h`, and `uchar.h` available?), and 2) OpenCL's `printf` is not really the same function as C's `printf` (https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#differences-between-opencl-c-and-c99-printf).

#1 is probably more of an oversight than anything, at least with the C11 headers. So maybe this isn't a super slippery slope, but maybe C23 will change that (I can imagine `stdbit.h` being of use in OpenCL for bit-bashing operations). However, the fact that the builtin isn't really `printf` but is `printf`-like makes me think we should make it a separate builtin to avoid surprises (we do diagnostics based on builtin IDs and we have special checking logic that we perhaps should be exempting in some cases).

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