This is the mail archive of the
mailing list for the GCC project.
Alexandre Oliva <firstname.lastname@example.org> writes:
> On Jul 4, 2007, David Edelsohn <email@example.com> wrote:
>>>>>>> Alexandre Oliva writes:
> Alexandre> It's as mechanical as the change you proposed, except that yours
> Alexandre> potentially loses information that would enable someone to recover
> Alexandre> !BEFORE_RELOAD_P() out of the expanded version of no_new_pseudos.
>> Except that no_new_pseudos was not used consistently.
> I'm not sure what you mean by "consistently", but regardless, how
> could any argument possibly make it better to replace it with
> (reload_in_progress || reload_completed)
> rather than
> such that anyone willing to clean things up from this point on may
> have to use complex grep patters to account for ongoing line breaks,
> reformatting and any other boolean transformations, just because it
> had to be expanded right away rather than retained as a macro?
> What I'm proposing is just that, instead of
> s/no_new_pseudos/(reload_in_progress || reload_completed)/g
> we use
> s/no_new_pseudos/!BEFORE_RELOAD_P ()/
> or at least keep no_new_pseudos as a macro that can be easily grepped
> for and doesn't break line length limits in current sources.
> I'm not asking for any actual cleanups to be reverted, just that we
> don't make it even harder to further clean it up. If taking out one
> of these three variables is good, taking out another of them is going
> to be better, right? Making it harder (or, more accurately, uglier)
> to do so isn't helping.
For the record, Alex puts my point of view perfectly here too.
I gather from the follow-ups that there's resistance to
s/no_new_pseudos/!BEFORE_RELOAD_P ()/ -- with BEFORE_RELOAD_P
defined as "reload_in_progress || reload_completed" until Alex's
follow-on change is implemented -- but I don't understand why.