This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 22/348] Fix -Wsahdow warnings
On Tue, Nov 22, 2011 at 9:29 PM, Andrey Smirnov
> On Tue, Nov 22, 2011 at 10:27 PM, Mike Frysinger <email@example.com> wrote:
>> On Tuesday 22 November 2011 09:04:07 Andrey Smirnov wrote:
>>> On Tue, Nov 22, 2011 at 8:35 PM, Marek Polacek <firstname.lastname@example.org> wrote:
>>> > On 11/22/2011 02:33 PM, Andrey Smirnov wrote:
>>> >>> Is the typo intentional?
>>> >> Sorry about that. No it isn't. Please ignore that particular patch I'll
>>> >> send corrected version soon(I'm in the middle of a git rebase
>>> >> --interactive, so I can't edit that particular commit just yet).
>>> > That typo is in other patches too.
>>> OK, once again, sorry about that, I'll recheck all the patches related
>>> to bcache.c, for now please ignore those.
>> please condense down your patches if you resend. ?there's way too many little
>> tiny ones that really should be squashed into a single changeset.
> Initially, there were 17 patches, which, upon suggestion from Tom
> Tromey, I split so that every patch contain only changes to one
> particular function or some other small unit of the source code. I
> tend to agree with Tom that my initial decision to make only 17
> patches made it rather hard to review each, because every one of them
> contained many small but disparate changes.
> Squashing or splitting commits is not really a problem and I can do
> this, but if you want me to do so, than please point out the patches
> I should squash together.
> Right now I have 258 patches to which I have yet to write a ChangeLog
> entry and 100 patches whose ChangeLog I have to change to, as you
> pointed out, conform to GNU policy. There are also patches that I
> screwed up with typos and patches that will eventually will have to be
> Squashing all commits based on file level will still leave you with
> something like 150 patches, but some of them would be quite large and
> harder to review than they are now. Doing so on API level would
> require me to go through all the patches and relative source code,
> figure out to what API every change belong(which I'll probably do wrong
> because I do not yet have a very good grasp on GDB's internals) and
> split and squash all commits accordingly.
> So given the aforementioned amount of work, can't we ignore that the
> patch count is over 9000?
> Andrey Smirnov
For reference sake, I did "grep -e -Wall ChangeLog*" to see what's
been done in the past. Based on that there is room for compromise I think.
Since these are just mechanical changes, and there are a lot of them,
I'd be happy with a compromise everyone is happy (or at least
not unhappy :-)) with.
I think keeping them at the file level is easiest for you (just
And I'd be happy with a changelog entry that simply said:
* foo.c: -Wshadow lint.
* foo.c (bar, baz): -Wshadow lint.
These are all just mechanical changes.
btw, I can imagine things regressing if we don't add -Wshadow
to configure.ac:build_warnings (say after the tree is clean).
We're agreed we want that right? Otherwise ...
Also, given the quantity, I'd suggest holding off until after 7.4 is branched.
[just a suggestion though]