> Huh, I see no reason for this rename. It'll just make patches across > releases harder.
Sure. But any change will make "patches across releases harder" ... does it mean we can't make any changes - not even in phase 1 ? :-( The reason I'd like to change the name is that "attribs.c" is meaningless. I never realized it contained code to deal with attributes until I opened the file and read the code inside. I always thought it contained some sort of mysterious internal GCC data structure or pass. Isn't that a good enough reason to rename it ? :-) Anyhow, if you want to keep the ugly name as it is, let's keep it that way. My next step was going to be to add an "attributes.h" file, moving into it the attributes functions (lookup_attribute(), is_attribute_p(), merge_attributes(), etc) from tree.h (and moving the corresponding implementations into attributes.c). The idea was to eventually have all the code dealing with attribute lists in these two files, so that it's easy to change the internal representation. And, there are few files actually accessing or manipulating attributes; only these files would include attributes.h, while the other ones - which include tree.h - wouldn't include or depend on the attribute functions. Can I go ahead with this or is it a waste of time as the patch will be rejected ? Presumably the new header file would need to be named "attribs.h", and I can't name it "attributes.h" ? Ouch. Thanks
