<div dir="ltr">As discussed on IRC, ISTM this would be better spelled as:<div>  typeid(<typename>).name();</div><div><br></div><div>The issue with that at the moment is that typeid() is an error if you build with -fno-rtti. However, there appears to be no reason why we cannot support `typeid(<typename>)` even with -fno-rtti. Unlike `typeid(<variable>)`, it requires no extra data to be emitted, since there's no possibility that dynamic dispatch is required. Therefore, similarly to how exception support still functions with -fno-rtti by emitting the explicitly required typeinfo data on demand, so too can typeid(<typename>).</div><div><br></div><div>I note also that when .name() is the only value used, the remainder of the typeinfo data is already omitted from the output when compiling with optimizations.</div><div><br>It looks like supporting this would be only be a few line change in clang, since all the underlying infrastructure is there already to support the EH with -fno-rtti use-case.</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 3, 2018 at 10:41 AM via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The concept itself is pretty trivial, the builtin takes one or two arguments, one of which<br>
has to be a pointer to an arbitrary type, this makes it particularly useful with C++<br>
auto declarations or even printing the type by simply casting a null pointer to<br>
the type in question. It's qualifiers are retained for the sake of printing them<br>
depending on the requested style.<br>
<br>
Implementation<br>
^^^^^^^^^^^^^^<br>
<br>
const char* TypeName =  __builtin_type_name(T* Ptr, [int Style])<br>
<br>
After validating either 1 or 2 argument form (ie. Pointed to type, and whether it's a <br>
record declaration), SemaChecking will set the return type to TheCall->setType(<br>
Context.getPointerType(Context.CharTy.withConst())) leaving it for Clang's CodeGen<br>
to deal with.<br>
<br>
Second argument is used to control the output format in form of a bitmask<br>
passed down to PrintingPolicy (as I port this I will decouple the values so the <br>
builtin's behavior isn't dependent on further changes in PrintingPolicy. At <br>
which point the type is retrieved using `getAsString` and stored in the CGM <br>
with `GetAddrOfConstantCString` allowing coalescing of those strings later <br>
during linking. as it's cast to a Int8Ptr.<br>
<br>
This is all done in Clang without needing to add anything to the LLVM core.<br>
<br>
Things left to do before submitting for code review<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
* There is no test coverage, so I need to write up a test file, comprehensively<br>
  testing cases I haven't considered before like Objective-C pointers, any<br>
  pointer to a special Clang type that may behave unexpectedly, complex<br>
  C++ templates (or simple ones, was my main use of it). Target is IR since<br>
  Clang fully lowers it, so in theory it's platform agnostic providing there is<br>
  enough space (the original use was for Embedded C++ with no RTTI.<br>
* While this is out of scope, a GUID buffer as a a style would provide a form<br>
  type IDs in absence of RTTI or alternatively smaller types like u32 or u16<br>
  (aimed at single module builds where they can remain unique, ie. embedded<br>
  systems with a kernel using those to represent kernel object types).<br>
<br>
Rationale<br>
^^^^^^^^^<br>
It's clear that this functionality is desired outside of embedded domain,<br>
typically with hacks involving a lambda and __PRETTY_FUNCTION__, on case<br>
being in `lib/Support/TypeName.h` in LLVMSupport. Many non-portable hacks<br>
that depend on compiler versions exist. This doesn't aim to be portable,<br>
just to be compact, not have a runtime cost, and provide this information<br>
either for debugging or even for more practical reasons.<br>
<br>
I wanted to find out if there was interest in this kind of thing since<br>
I have developed a variety of different useful and not so useful extensions,<br>
originally for embedded use but I want to upstream them for general use,<br>
I want to know what the consensus is on 1) This particular extension<br>
2). Further extensions that were originally developed for embedded use<br>
but have turned out to be useful in a lot of contexts where you are willing<br>
to sacrifice portability  (now with `__has_builtin` this is extremely easy to <br>
test for and fallback on something else).<br>
<br>
On the other hand it's a lot to do overall so I would prefer to get a consensus<br>
whether each feature (even this small one) is worth cleaning up and putting<br>
up for code review, since I understand that something like builtin bloat<br>
or non portability may be of concern. As for the formal name I'd like to call<br>
it extensions for Embedded C++ 2 gating it behind an opt-in flag such as<br>
`-fecxx2-extensions`.<br>
<br>
Other things involve limited reflection retrieving the bare minimum that's<br>
needed, a llvm::formatv style formatter accelerator, getting names of record<br>
scope at different levels with 0 being similar to the desired __CLASSNAME__ <br>
macro (at least by some).<br>
<br>
Looking forward to any feedback whether positive or negative.<br>
Thank you for your time.<br>
- Kristina<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>