From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Remove duplicate or commented-out #includes
Date: Mon, 21 Jan 2019 17:34:00 -0000 [thread overview]
Message-ID: <8308e985e1e6893e17b968fd7b74c90b@polymtl.ca> (raw)
In-Reply-To: <20190119213007.23712-1-tom@tromey.com>
On 2019-01-19 16:30, Tom Tromey wrote:
> I wrote a little script to detect duplicate or commented-out #includes
> and ran it on gdb. This patch is the result. Tested by rebuilding.
Nice, thanks, this LGTM.
> It would be possible to sort #includes, or maybe run
> include-what-you-use on gdb, but I haven't tried that. I'd be
> interested to hear if you think this would be worthwhile, thoug.
I wasn't sure of what the advantage of using IWYU was, so I read this:
https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/WhyIWYU.md
In the end, removing unnecessary includes would be nice. If a .c file
includes a header file unnecessarily, it will be rebuild for nothing
when that header file is modified. If we can avoid that, it means less
wasted time for everybody. Replacing includes by forward declarations
is also nice to cut down on compilation time. It would be really
tedious to do those changes by hand, but if a tool can do it
automatically, why not.
We have that policy where .h files must assume that defs.h has been
included (providing common types) [1]. I am not sure how IWYU will cope
with that.
[1]
https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Include_Files
> gdb/ChangeLog
> 2019-01-19 Tom Tromey <tromey@bapiya>
>
> * ui-out.c: Fix includes.
> * tui/tui-source.c: Fix includes.
> * target.c: Fix includes.
> * remote.c: Fix includes.
> * regcache.c: Fix includes.
> * python/py-block.c: Fix includes.
> * printcmd.c: Fix includes.
> * or1k-tdep.c: Fix includes.
> * mi/mi-main.c: Fix includes.
> * m32r-tdep.c: Fix includes.
> * csky-tdep.c: Fix includes.
> * compile/compile-cplus-types.c: Fix includes.
> * cli/cli-interp.c: Fix includes.
>
> gdb/gdbserver/ChangeLog
> 2019-01-19 Tom Tromey <tromey@bapiya>
>
> * tracepoint.c: Fix includes.
> * remote-utils.c: Fix includes.
> * linux-x86-low.c: Fix includes.
>
> gdb/stubs/ChangeLog
> 2019-01-19 Tom Tromey <tromey@bapiya>
>
> * ia64vms-stub.c: Fix includes.
Watch out for that email address in the ChangeLog entries.
Simon
next prev parent reply other threads:[~2019-01-21 17:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-19 21:31 Tom Tromey
2019-01-21 17:34 ` Simon Marchi [this message]
2019-01-21 18:28 ` Tom Tromey
[not found] ` <20190121172843.GA7007@blade.nx>
2019-01-22 4:07 ` Tom Tromey
2019-01-23 4:00 ` Tom Tromey
2019-01-23 16:40 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8308e985e1e6893e17b968fd7b74c90b@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox