[cfe-dev] Pseudo-functions taking types as arguments - keywords?

[Douglas Gregor]

On Dec 29, 2008, at 6:38 AM, Sebastian Redl wrote:
> I just implemented the POD property of C++ classes,

Great!

> but to test it, I
> also need a way to determine if a class is a POD. Since the rules in  
> the
> C++ standard only specify runtime behaviour of PODs, I can't use  
> those.
> I'm therefore looking to type traits, which expose this information.

The only detectable compile-time behavior I can think of for POD types  
is [dcl.init]p9, which says that for a const uninitialized variable of

	const X x;

X either needs to be a POD or needs to have a user-declared default  
constructor. We don't check that condition at the moment, since we  
don't have a way to check for POD types, although there's an #if 0'd  
spot for it in Sema::ActOnUninitializedDecl. Unfortunately, we haven't  
fixed the linkage-specification issues yet that caused that code to be  
#if'd out.

>
> To implement TR1 type traits, the compiler must provide some sort of
> help. In GCC, this help takes the form of about 15 type-traits  
> extension
> built-ins, like __is_pod, __is_abstract, __has_trivial_constructor,  
> etc.
> These built-ins take the form of unary and binary functions that take
> types as arguments and return a bool constant expression. So my goal  
> is
> to implement the __is_pod, and the only sane way to do this is to
> provide the infrastructure for all these type traits.

This is a great idea.

>
> The question is, how do I implement the names of these functions? If
> they are normal identifiers, their arguments will be mis-parsed,  
> unless
> I introduce a lot of special cases in the parser. However, it's a  
> lot of
> keywords to add. Thus, I'm wondering if Clang has some pre-established
> way of handling such things.


Clang's IdentifierInfo structure has a field that's set to a non-zero  
"builtin ID" for builtin function names (such as  
"__builtin_constant_p"); see IdentifierInfo::getBuiltinID/ 
setBuiltinID. The target-independent builtins themselves are declared  
in include/clang/AST/Builtins.def and there are various target- 
dependent builtins as well (e.g., X86Builtins.def).

Now, all of these builtins are functions that operate on values, not  
on types, so the mechanism would probably need to be extended a bit  
for the type-trait functions (say, by specifying the type of the  
function as "T"). The parser will need to be able to distinguish  
between builtins that operate on values vs. builtins those that  
operate on types, but I think such a change won't be terribly complex.

	- Doug