emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Make byte-compile-error-on-warn a safe variable for file com


From: Robert Cochran
Subject: Re: [PATCH] Make byte-compile-error-on-warn a safe variable for file compilation
Date: Thu, 04 Jan 2018 22:17:51 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Noam Postavsky <address@hidden> writes:

> On Thu, Jan 4, 2018 at 4:40 AM, Robert Cochran
> <address@hidden> wrote:
>
>> Attached is a patch that adds the variable `byte-compile-error-on-warn'
>> to the safe variable list temporarily during calls to
>> `byte-compile-file`, so that individual files can easily and simply
>> include "byte-compile-error-on-warn: t" in their file local variables.
>
> Wouldn't it be simpler and clearer to make it permanently safe? (PS
> you can use #'booleanp instead of listing t and nil).

I somehow came to the conclusion that the way I did it was the simplest
and cleanest to me. I noticed that `safe-local-variable-values' is nil
by default and I took that as a hint (rightly or wrongly) to not touch
the value directly. I was also aiming to prevent easily tampering with
the variable, again, however right or wrong that particular decision
seems to you.

On that topic, since `safe-local-variable-values' is nil by default,
where is it exactly that you would recommend I add this variable? A few
quick greps didn't give me any clear ideas.

Thanks for your suggestion about using #'booleanp, btw.

>
>> For example, something that is bothering me right now
>> is that there are quite a few 'foo is obsolete' warnings during the byte
>> compilation portion of the build phase. Enabling error on warning means
>> that trying to byte compile files that reference stale
>> functions/variables/what have you will fail, prompting patches that
>> obsolete Lisp objects to also fix usage of it in the core with the
>> appropriate recommended replacement.
>
> Solving Bug#4837 would be helpful for this, as currently there is no
> practical way to fix/suppress the obsolete warnings in the code that
> remains to support the obsolete option.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=4837

Yeah, I was thinking about that. In private discussion with friends, it
was mentioned that it could be a `declare' option - something like
(declare no-warn-obsolete) - but that's not very satifying for anything
other than defuns.

This is why I was wanting the file local variables. It can be turned on
slowly as warnings are fixed, in a similar vein to
lexical-bindings. Even if we find that there are a few files where it
can't be enabled, it can at least be enabled on the vast majority of
them.

My $0.02 of course.

Thanks,
-- 
~Robert Cochran

GPG Fingerprint - BD0C 5F8B 381C 64F0 F3CE  E7B9 EC9A 872C 41B2 77C2



reply via email to

[Prev in Thread] Current Thread [Next in Thread]