Re: Fixing compilation and byte-compilation warnings before 25.1

[Paul Eggert <eggert@cs.ucla.edu>]

On 11/13/2015 07:46 AM, John Wiegley wrote:
> The policy should be: We never have warnings in our build on GNU Linux

That's a good goal, but the devil's in the details and the details 
aren't written down. Here's a first cut at the current situation; 
comments welcome. I suppose something like this should go into a text 
file somewhere....


I run "./configure --enable-gcc-warnings" on Fedora x86-64 with the 
latest GCC, and rewrite the code to fix all C-level warnings that this 
uncovers. This doesn't fix all warnings for older GCC versions, or for 
non-GCC compilers, or for x86 or sparc, or for code that is #ifdeffed 
out or not compiled on my plastform, etc. Some of these are not worth 
the hassle (e.g., older compilers) as the cost of code-clutter is not 
worth the benefit of possibly finding bugs with older compilers. Others 
are worth doing (e.g., non-x86-64 platforms, non-Fedora distros) but I 
lack the time and/or system access and it'd be nice if someone would 
volunteer.

I also occasionally run valgrind on Emacs executables (actually, 
temacs), and try to fix the warnings it generates. This is considerably 
harder to do, but is a real nice thing to have on our checklist.  (Right 
now, for example, there are a couple of memory-allocation bugs that I 
really would rather be fixing than writing administrative text like 
this. :-)

It'd be nice if someone would volunteer to clean up Elisp warnings (and 
thanks, Juanma, for volunteering to help). For these I see the following 
classes:

* Warnings where people install changes to .el files but don't bother to 
fix the warnings. I hope these are rare. We really need to get out of 
the habit of doing this.

* Warnings where people change module X but don't clean up the warnings 
that this causes to modules other than X. It's a hassle for developers 
to catch these ('make compile-always' is little-known and expensive). 
Perhaps our autobuild process could catch these and send email to the 
developer whose changes to X causes warnings in Y.

* Warnings where people change the byte-compiler to generate new, useful 
warnings, but don't clean up all the .el files accordingly. Here it can 
be a bit much to expect the developer to clean up everyone else's code. 
But it'd be nice if volunteers could strive to get these fixed while 
preparing for a release.

* Warnings generated because code is intended to be portable to XEmacs 
or to older GNU Emacs, and so uses deprecated interfaces on purpose. As 
far as I know there's no convenient way to say "I know FOO is 
deprecated, I want to use it anyway, don't issue a warning" in code that 
will also work in older Emacs. This should get fixed.