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

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> > 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).
> 
> Understood. Then I propose the following.
> 
>     1. Currently Builtin TableGen does not seem to support specifying lang address spaces in function prototypes. this needs to be implemented first if not already in development.
> 
>     2. We could have two new macro variants probably named "OCL_BUILTIN" and "OCL_LIB_BUILTIN" which will take the ID's of the form "BI_OCL##<builtin_name>". we would also need corresponding TableGen classes (probably named similar to the macros) which can expose such overloaded prototypes when required.
> 
> 
> How does this sound ?

I think that sounds like a reasonable way forward, thank you!

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