On Tue, Oct 6, 2015 at 11:43 PM, Jeff Law <l...@redhat.com> wrote: > On 10/05/2015 02:10 PM, Andrew MacLeod wrote: >>> >>> >>> Is the bitmap/obstack example really one of a change that is >>> desirable? I think if a file uses obstacks then an include of >>> obstack.h is perfectly fine, giving us freedom to e.g. change bitmaps >>> not to use obstacks. Given that multiple headers include obstack.h, >>> and pretty much everything seems to indirectly include bitmap.h >>> anyway, maybe a better change would be to just include it always in >>> system.h. >> >> >> Its just an example of the sort of redundant includes the tool removes. > > It may not be the best example. The tools don't treat obstack specially > (nor should they IMHO). So let's pretend it's not obstack.h which has been > arguably a core part of GCC for a long time. > >> >> I don't see the point in leaving redundant #includes in the source >> code because of direct uses from that header in the source. I'm not >> even sure how I could automate detecting that accurately.. Going >> forward, If anyone ever makes a change which removes a header from an >> include file, they just have to correct the fallout. heh. Thats kinda >> all I've done for 4 months :-) At least we'll have grasp of the >> ramifications.. > > And the last sentence is the key here. We're trying to get to a point where > we can make certain kinds of changes, then have the compiler spit out > errors, fix the errors and have a high degree of confidence that the final > change is correct and that we've found all the places that need to change. > > The change could be as simple as moving a function declaration to its > natural place, collecting interfaces & data into classes, or something more > ambitious like removing trees from the backend. Folks will note that these > are all refactorings that we don't want to change any observable behaviour. > > > > > >>> * diff -c is somewhat unusual and I find diff -u much more readable. >> >> >> unsual? I've been using -cp for the past 2 decades and no one has ever >> mentioned it before... poking around the wiki I see it mentions you >> can use either -up or -cp. >> >> I guess I could repackage things using -up... I don't even know where >> my script is to change it :-). is -u what everyone uses now? no one >> has mentioned it before that I am aware of. > > I'm probably the last person in the world that still generally prefers -cp > :-) I'm getting to the point where I can tolerate -u.
No, I prefer -cp too - diff just too easily makes a mess out of diffs with -u, esp. if you have re-indenting going on as well. Richard. > >> >> >>> * Maybe the patches for reordering and removing should be split, also >>> for readability and for easier future identification of problems. >>> >> I was trying to avoid too much churn on 550ish files... I didn't think >> each one needed 2 sets of check-ins. It could be done, but it will >> take a while. The reordering patch can be quickly generated, but the >> reduction on all those files will take the better part of a week. >> >> My theory is it perfectly safe to back out any single file from the >> patch set if we discover it has an issue and then examine what the root >> of the problem is.. >> >> tool patch coming shortly... probably tomorrow now. > > I haven't looked at the 3 patches in detail yet. Given my familiarity with > the overall process/goal, I can probably handle them as-is. They're just big > mechanical changes. > > jeff
