[cfe-dev] [Proposal]: Fast non-portable extension to retrieve a type name from a pointer as a GV: __builtin_type_name(T* Ptr, [int Style])

[via cfe-dev]

The concept itself is pretty trivial, the builtin takes one or two arguments, one of which
has to be a pointer to an arbitrary type, this makes it particularly useful with C++
auto declarations or even printing the type by simply casting a null pointer to
the type in question. It's qualifiers are retained for the sake of printing them
depending on the requested style.

Implementation
^^^^^^^^^^^^^^

const char* TypeName =  __builtin_type_name(T* Ptr, [int Style])

After validating either 1 or 2 argument form (ie. Pointed to type, and whether it's a 
record declaration), SemaChecking will set the return type to TheCall->setType(
Context.getPointerType(Context.CharTy.withConst())) leaving it for Clang's CodeGen
to deal with.

Second argument is used to control the output format in form of a bitmask
passed down to PrintingPolicy (as I port this I will decouple the values so the 
builtin's behavior isn't dependent on further changes in PrintingPolicy. At 
which point the type is retrieved using `getAsString` and stored in the CGM 
with `GetAddrOfConstantCString` allowing coalescing of those strings later 
during linking. as it's cast to a Int8Ptr.

This is all done in Clang without needing to add anything to the LLVM core.

Things left to do before submitting for code review
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* There is no test coverage, so I need to write up a test file, comprehensively
  testing cases I haven't considered before like Objective-C pointers, any
  pointer to a special Clang type that may behave unexpectedly, complex
  C++ templates (or simple ones, was my main use of it). Target is IR since
  Clang fully lowers it, so in theory it's platform agnostic providing there is
  enough space (the original use was for Embedded C++ with no RTTI.
* While this is out of scope, a GUID buffer as a a style would provide a form
  type IDs in absence of RTTI or alternatively smaller types like u32 or u16
  (aimed at single module builds where they can remain unique, ie. embedded
  systems with a kernel using those to represent kernel object types).

Rationale
^^^^^^^^^
It's clear that this functionality is desired outside of embedded domain,
typically with hacks involving a lambda and __PRETTY_FUNCTION__, on case
being in `lib/Support/TypeName.h` in LLVMSupport. Many non-portable hacks
that depend on compiler versions exist. This doesn't aim to be portable,
just to be compact, not have a runtime cost, and provide this information
either for debugging or even for more practical reasons.

I wanted to find out if there was interest in this kind of thing since
I have developed a variety of different useful and not so useful extensions,
originally for embedded use but I want to upstream them for general use,
I want to know what the consensus is on 1) This particular extension
2). Further extensions that were originally developed for embedded use
but have turned out to be useful in a lot of contexts where you are willing
to sacrifice portability  (now with `__has_builtin` this is extremely easy to 
test for and fallback on something else).

On the other hand it's a lot to do overall so I would prefer to get a consensus
whether each feature (even this small one) is worth cleaning up and putting
up for code review, since I understand that something like builtin bloat
or non portability may be of concern. As for the formal name I'd like to call
it extensions for Embedded C++ 2 gating it behind an opt-in flag such as
`-fecxx2-extensions`.

Other things involve limited reflection retrieving the bare minimum that's
needed, a llvm::formatv style formatter accelerator, getting names of record
scope at different levels with 0 being similar to the desired __CLASSNAME__ 
macro (at least by some).

Looking forward to any feedback whether positive or negative.
Thank you for your time.
- Kristina