[Top][All Lists]

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

Re: Solving some specific warnings (was: Fixing compilation and byte-com

From: daniel sutton
Subject: Re: Solving some specific warnings (was: Fixing compilation and byte-compilation warnings before 25.1)
Date: Sat, 14 Nov 2015 12:49:27 -0600

Thank you so much for the response Artur. I actually saw someone post a link to a blog post of yours about the using # before lambdas today as well (just saying that your contributions are passed around the community and are much appreciated).

I can add (with-no-warnings (recursive-call-to-deprecated-args-list ...)...) calls to the warnings of this type. However, do you have any thoughts about trying to modify the declare statements? It seems like this declare should be for consumers of the function rather than inside of the function. I wasn't sure if we could have the compiler check if it was being called from within the actual original definition of a function and therefore be smart enough to not issue a warning, or if we could add some type of declaration that this is the core so the warnings are not for us.

My hesitation are that some of these might be heavy handed and might make the core more brittle as time goes on and no warnings are issued when things change more. It also might be as tedious as wrapping each call with a with-no-warnings.

I see that with-no-warnings is defined like this:
(defun with-no-warnings (&rest body)
  "Like `progn', but prevents compiler warnings in the body."
  (declare (indent 0))
  ;; The implementation for the interpreter is basically trivial.
  (car (last body)))

I see nothing that obviously suppresses warnings, so it seems like the interpreter checks to see if it is inside of this environment. Could we change the interpreter to check if its running inside of a function with a (declare (advertised-calling-convention (signature) "version")) and issue no warnings about advertised-calling-convention violations?

Lots of rambling and words there but mundane problems can have interesting solutions. Thanks so much and I hope you're having a great weekend.

On Sat, Nov 14, 2015 at 6:05 AM, Artur Malabarba <address@hidden> wrote:
Hi Daniel

2015-11-14 5:54 GMT+00:00 daniel sutton <address@hidden>:
> Hello everyone. I'm a bit new to mucking about in the internals of emacs but
> wanted to help out with cleaning up some compiler and byte compiler
> warnings.


> I'm building and noticing the error
> minibuffer.el:1697:12 display-completion-list called with 2 arguments but
> accepts only 1.
> I'm a little confused as the this function has this signature:
> (defun display-completion-list (completions &optional common-substring) ...)
> In fact, this is a recursive call inside of the function
> display-completion-list.

This is because `display-completion-list' includes the line (declare
(advertised-calling-convention (completions) "24.4")).

This means that, since 24.4, the old way of calling this function was
made obsolete, and it should only be called with one argument now.
Instead of just removing the second argument entirely (which would
break backwards compatibility of code out there) we "pretend" that the
function only takes one argument, so that new code won't use the
second argument.

Normally, the way to solve this warning is to update the way that the
function is being called to conform with the new arglist.
However, looking at the source here, it seems that if the clause `(not
(bufferp standard-output))' is true, then the function just wants to
call itself again (with the same arguments) in a temp-buffer, so you
shouldn't change that.

So it is safe to just mute this warning (and add a comment to the
function saying why). To mute the warning, wrap the form in a
`(with-no-warnings ...)'

reply via email to

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