Re: Fixing compilation and byte-compilation warnings before 25.1

[Artur Malabarba]

daniel sutton <address@hidden> writes:

> 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 wouldn't do.
This would mean that you would never get a callargs warning inside a
function that declares `advertised-calling-convention', _even_ warnings
that pertain to calls to _other_ functions. 

So it would have to be smarter than that, and only suppress the warning
if it pertains to this very 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.

You should know, I don't think this sitation of “function with obsolete
calling convention that recursively calls itself” is actually that
common. 

If you'd like to try your hand at this, by all means, have fun. :-)
The cause sounds reasonable to me, as long as the solution doesn't
turn out horribly complex it should be a nice addition.
I just thought you should know that.