On Wed, Jun 22, 2011 at 8:36 PM, Nicola Pero <nicola.p...@meta-innovation.com> wrote: >> 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 ? :-(
No, not in general. > 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 ? :-) Hmm, attribs.c to me is a perfect abbreviation to attributes.c, so it isn't unclear (to me) ... there are more confusing file names, like tree-dfa.c or tree-flow*.[ch]. > 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). That sounds fine (then with the name attribs.h). > 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 ? No, that sounds good and is welcome. > Presumably the new header file would need to be named "attribs.h", and I > can't name it > "attributes.h" ? Ouch. ;) Another maintainer may feel free to override my initial reaction. Thanks, Richard. > Thanks > >
