Re: Fixing compilation and byte-compilation warnings before 25.1

[daniel sutton <danielsutton01@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

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 <michael_heerdegen@web.de
> wrote:

> daniel sutton <danielsutton01@gmail.com> 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.
>
>
> Michael.
>
>
>

[-- Attachment #2: Type: text/html, Size: 3415 bytes --]