bug#61730: 30.0.50; Compiler warnings for delq and delete

[Eli Zaretskii <eliz@gnu.org>]

> From: Richard Stallman <rms@gnu.org>
> Cc: 61730@debbugs.gnu.org
> Date: Sun, 26 Feb 2023 22:24:27 -0500
> 
>   > In Emacs maintenance and development, the two cases are actually one.
>   > We rebuild Emacs so frequently that even a "rare" warning appears all
>   > the time and is annoying.  It is not a coincidence that we usually
>   > don't tolerate warnings during the build of Emacs.
> 
> I am surprised -- I didn't do that when I was the main maintainer.

We have more branches than back then.  I routinely build 3 branches
every day -- master, the release branch, and a feature branch for some
long-living feature.  I build 3 more branches weekly.  So I see the
same or similar warnings more than once each day.  The situations
where many Lisp files need to be recompiled are also more frequent
nowadays, due to a much more massive use of macros.  These reasons add
up.

> In recent years, ISTR seeing warnings in the build often enough.

You are tracking the master branch, which is by definition less clean
wrt warnings.

> I resent it when a compiler takes up my time pressuring me to prove to
> it that I know something isn't a bug, and I usually tell that compiler
> (inside my head) where it can take those warnings.

Likewise.  Although the place I use (in my head) is called by a
somewhat different name.  But is similar in nature.

> When I implemented the options that enable such warnings in GCC, I
> urged people NOT to use those options by default.  To enable them by
> default in a makefile is to impose systematic harassment on every
> contributor to the code.  You end up with a program as your
> taskmaster, haranguing you continually to insert proof that you didn't
> make some mistake.

Sadly, that stance is all but gone nowadays: compilers, including GCC,
wine too much, especially if you use "-Wall", and many projects use
"-Wall" by default.  That is called "progress".

End of rant.