[cfe-commits] PATCH [1/2]: Implementation of Embarcadero expression traits

Abramo Bagnara abramo.bagnara at gmail.com
Tue Feb 22 00:09:28 PST 2011


Il 22/02/2011 02:38, Douglas Gregor ha scritto:
> 
> On Feb 19, 2011, at 12:41 AM, Abramo Bagnara wrote:
> 
>> Il 18/02/2011 23:53, John Wiegley ha scritto:
>>> Patch authored by David Abrahams.
>>>
>>> These two expression traits (__is_lvalue_expr, __is_rvalue_expr) are used for
>>> parsing code that employs certain features of the Embarcadero C++ compiler.
>>
>> I don't see the point for introducing another AST node
>> (ExpressionTraitExpr): __is_lvalue_expr/__is_rvalue_expr are
>> conceptually equivalent to e.g. __builtin_constant_p.
>>
>> I think they should be implemented in the same way.
>>
>> I'm missing something?
> 
> I'd really rather avoid using a __builtin-like mechanism for this, because that implies that we're actually calling a function with a signature like
> 
>   bool __is_lvalue_expr(…);
> 
> However, we really don't want the ellipsis conversion to occur on the argument, nor do we want to accept multiple arguments, or add hacks to Sema to work around the limitations of the built-in handling mechanism.
> 

We already do all that for __builtin_constant_p and a bunch of other
__builtins. Probably we'd need only a builtin signature specifier
different from "." that means "exactly one argument of whatever type".

Another alternative might be to move all these builtin to
ExpressionTraitExpr, but IMHO it is not a good idea: to have all
call-like expression (whose arguments are expression) in a single place
is a good thing.

My point is that really I don't see any difference between
__is_lvalue_expr and __builtin_constant_p.



More information about the cfe-commits mailing list