Re: PATCH: Generalize tree-dumping infrastructure

[Per Bothner <per at bothner dot com>]

Jason Merrill wrote:

>This is necessary for the high-level tree representation of the code; a C++
>if statement can have a declaration in the condition, declaring a variable
>only visible in the affected block(s).
>
Hm.  Let us look at this argument.

In tree.def:
/* Conditional expression ( ... ? ... : ...  in C).
   Operand 0 is the condition.
   Operand 1 is the then-value.
   Operand 2 is the else-value.
   Operand 0 may be of any type.
   Operand 1 must have the same type as the entire expression, unless
   it unconditionally throws an exception, in which case it should
   have VOID_TYPE.  The same constraints apply to operand 2.  */
DEFTREECODE (COND_EXPR, "cond_expr", 'e', 3)

In c-common.def:
/* Represents an 'if' statement. The operands are IF_COND,
   THEN_CLAUSE, and ELSE_CLAUSE, respectively. */
DEFTREECODE (IF_STMT, "if_stmt", 'e', 3)

What do you know - they're the same!  Nothing about declarations.
No extra slots where a declaration may be stashed.  No reason I can
see why you can't use COND_EXPR.

The key issue is how expand_expr handles COND_EXPR vs IF_STMT.
I see that COND_EXPR does a bunch of optimizations that IF_STMT
doesn't, and IF_STMT handles some "nesting" that COND_EXPR
doesn't.
    --Per