Reorder some tree codes

[Daniel Berlin]

>>> 
>>> 
>>> 
>>> I do not like this because we lose clarity in the definition of the 
>>> macros, and
>>> thus we make debugging much harder.
>> 
>> 
>> It's not just that, it's that the in_range changes mean that the compiler 
>> will break if you move tree codes around in tree.def.
>
> As I've said, I'm concerned about that too -- but I think calling it "just 
> wrong" is too strong.  The style of range-checking enumeration constants is 
> very common in lots of code, and I don't see anything wrong with that. 
> What's a little different here is that tree codes are strewn around over lots 
> of places.

The other difference is that we have no explicit markers that make it 
clear where to insert things without looking at the tree.h in_range 
checks.


IE we don't have the equivalent of "first_primary_color" and 
"last_primary_color" in your example below.


>  enum color {
>    first_primary_color = 0,
>    blue = 0,
>    red,
>    yellow,
>    last_primary_color = yellow,
>    purple,
>    turquoise,
>    mauve
>  };
>

If we had enumeration values named approriately and equal to the things he 
was testing in the range checks (ie we had 
FIRST_DECL_CODE/LAST_DECL_CODE, and that was what was being tested again), 
that would be fine by me.

I just don't like that i have to figure out the endpoints of what is being 
tested by hunting down how the code is actually doing it, instead of it 
being clear just from tree.def.

I also think that having the endpoints explicitly delineated in tree.def 
would solve the problem of people reordering the codes without noticing it 
might break things.

--Dan