Re: [Patch] Enable byte-compile-error-on-wran for error-free files in lisp/

[Eli Zaretskii]

> From: Robert Cochran <address@hidden>
> Date: Wed, 21 Feb 2018 19:05:11 -0800
> Cc: address@hidden
> 
> > I sometimes consider it preferable to keep a warning than to silence it
> > (typically because I can't fix it (yet)).  This said, I'm fine with
> > adding such annotations for those files which currently don't have warnings.
> 
> Yeah, right now it is only marking files that emit no warnings
> whatsoever.

I don't see why a file that today emits warnings should be exempted
from the policy (if we accept it).  I think the current state of
affairs is entirely accidental, in the sense that it is the result of
the fact that no one has seriously worked yet on the files that do
emit warnings.

So I find this aspect of the proposed change puzzling.  Either we care
about the warnings or we don't.  If we do, we shouldn't tolerate them
anywhere.

> I intend for this to be a situation similar to lexical-binding,
> where it is enabled on a per file as they get cleaned up and become
> warning-free.

Lack of lexical-binding was not an evidence of something being wrong
with the file.  So I don't see the analogy there.

> I am trying to keep warnings from lingering. The
> string-{to,as}-{multi,uni}byte family of functions have been deprecated
> since June 2016, which are some of the functions I see the most in the
> deprecation warnings. Stuff like that.

I don't see how stopping the build will miraculously help us fix these
warnings in a reasonably correct way.  These warnings are hard to fix
(see my other message about that).  Moreover, there are warnings
triggered by bugs or misfeatures in the byte compiler -- e.g., try
byte-compiling gud.el.  They can be shut up by kludgey workarounds,
but do we really want our code to use such kludges, just to avoid the
warnings?

I predict that the result of making warnings stop the build will be
abundance of kludges in the code, which will not be adequately
explained in the sources, and so 10 years from now we will have the
same situation as with string-to-unibyte, where no one really knows
why we do that, and how to test whether the original reason is gone.

IMO, the only way to eliminate the warnings is to start the work on
fixing them one by one.  This requires motivated individuals, and this
requires time.  Making warnings break the build is not the right way,
IMO, it will just harm development by diverting part of our scarce
resources to inventing kludges.