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

[Douglas Gregor]

On Feb 22, 2011, at 12:30 AM, John McCall wrote:

> 
> On Feb 22, 2011, at 12:09 AM, Abramo Bagnara wrote:
> 
>> 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.
> 
> Well, __builtin_constant_p's argument is always considered as an r-value, for one.
> 
> We already have some builtins with nonstandard type-checking semantics, though;  these seem much the same.  I think we should just mark the builtins as special, make GatherArgumentsForCall a no-op for them, and make the builtin semantics checkers do all the right things.

... and note that the expression is parsed as a constant-expression, so that we don't instantiate templates in it. For example, while this code is ill-formed in GCC and Clang:

  template<typename T> T f(T) {
    T * x = 1;
  }

  int main() {
    __builtin_constant_p(f(17)); // f<int> is marked "used", instantiated, and fails
  }

we need to make sure that the argument to __is_lvalue_expr and __is_rvalue_expr is parsed (and instantiated) as an unevaluated operand. If there's a clean way to push that from the builtins definition to the parser and TreeTransform, then yes, I'd agree that a builtin-based solution would be preferred.

	- Doug