[Top][All Lists]

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

Re: Fixing compilation and byte-compilation warnings before 25.1

From: daniel sutton
Subject: Re: Fixing compilation and byte-compilation warnings before 25.1
Date: Mon, 16 Nov 2015 08:15:59 -0600

There could be some value to that. My thinking is that the declaration that there should be only one argument passed is kinda like a keep off the grass sign, but then the compiler is throwing a warning that the keep off the grass sign is actually on the grass. The consumers of this should have a warning, but since we are handling legacy behavior (of passing two arguments) there should be no warning inside of this function. When things change, ie, if we remove the optional argument, then we would immediately know if we forgot to change things because then this would be an error, as the argument mismatch was very obvious. 

I certainly agree that blindly suppressing all warnings is not a good call. I'm investigating the way that the compiler works, as I'm very new to this. My thinking is that we may have local definitions of byte-compile-enable-warnings that include (not callargs) *only* when compiling a function that contains a (declare (advertised-calling-convention (newArgs) "version")). This would make sure that others that hit this would be warned about the api shift but allow "bad" calls to it to still work. Then, when the optional argument is finally removed, if someone forgot to remove the old call, again, inside of the original defun, it would be a compiler error and not warning. But presumably, if you are changing the function signature like this you would be responsible for the entire body of the function.

Again, this is a proposal only for this specific type of warning, and not just suppressing warnings inside of the core. I want warnings to be informative and a cause of action, not to be ignored. This warning is superfluous and should be removed. If the best case is just a (with-no-warnings ...) so be it, but I think there is a more clever solution here, and one that actually fits the nature of what is being done with a advertised-calling-convention change.

On Sun, Nov 15, 2015 at 6:41 AM, Michael Heerdegen <address@hidden> wrote:
daniel sutton <address@hidden> writes:

> Ah thank you. Someone responded and made a new thread and were super
> helpful as well. It seems like this warning needs to go to new
> consumers but not in the core. Would it be appropriate for the declare
> statement to somehow tell the compiler that we are in the core and
> therefore to suppress warnings of this type?

I don't think that suppressing blindly all warnings of any particular
type is a good idea.  Some of them might indicate problems.

> One suggestion was to add the recursive call into a (with-no-warnings
> ...) call, but this could get tedious and invasive.

Why not just leave this one particular warning?  It reminds us we still
have something to change there in the future.


reply via email to

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