From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Serghei Iakovlev <egrep@protonmail.ch>
Cc: GNU Emacs Developers <emacs-devel@gnu.org>
Subject: Re: esup byte compile warnings
Date: Wed, 29 Jan 2020 09:32:18 -0500 [thread overview]
Message-ID: <jwveevigxbd.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <104542A5-436D-44DB-AEE2-9DB5D64FAC01@protonmail.ch> (Serghei Iakovlev's message of "Wed, 29 Jan 2020 12:56:40 +0000")
> Consider the following defun:
>
> (defun esup-total-exec-time (results)
> "Calculate the total execution time of RESULTS."
> (cl-loop for result in results
> sum (slot-value result 'exec-time) into total-exec-time
> finally return total-exec-time))
>
> This produces a waring:
>
> In esup-total-exec-time:
> esup.el:166:52: Warning: Unknown slot ‘exec-time’
This warning means that the bytecompiler has not seen any `defclass`
that defines a slot `exec-time`. Maybe it's perfectly normal (you know
that the object will indeed have an `exec-time` slot when that code will
be executed), e.g. because the object will be created in another file
which is not `require`d in this file, but without knowing more about
this slot it's hard to tell what's the best way to address the warning.
[...looking at https://github.com/jschaf/esup...]
Oh, I think it's because of
(let ((load-path (append load-path (list esup-load-path))))
(require 'esup-child))
which means that the `require` won't be executed by the byte-compiler
(because it's within a `let`). Either you should just drop this
`load-path` trickery (and push the responsability of `load-path`
manipulation to the code that byte-compiles the files, as usual), or you
may want to wrap this within an `eval-and-compile`.
> Looks like the reason is that the byte-compiler unable to match
> ‘result’ with the class declaration.
The compiler doesn't even try to infer types. It only checks that some
class somewhere has defined a slot of that name (that's good enough to
catch most typos).
Stefan
PS: While I'm here I noticed:
(eval-when-compile
(if (and (<= emacs-major-version 24)
(<= emacs-minor-version 3))
(require 'cl)
(require 'cl-lib)))
which makes no sense: those two libraries provide the same *kind* of
functionality, but under completely different names. The rest of the
code uses things like `cl-loop`, so you need to (require 'cl-lib)
because that's what the code uses. In Emacs<24.4, `cl-lib` will itself
load `cl` (because it uses it internally, but that's an implementation
detail).
next prev parent reply other threads:[~2020-01-29 14:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-24 20:48 esup byte compile warnings Serghei Iakovlev
2020-01-24 21:55 ` Stefan Monnier
2020-01-29 12:56 ` Serghei Iakovlev
2020-01-29 14:32 ` Stefan Monnier [this message]
2020-01-29 14:42 ` Serghei Iakovlev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwveevigxbd.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=egrep@protonmail.ch \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.