From: Alan Mackenzie <acm@muc.de>
To: Markus Triska <markus.triska@gmx.at>
Cc: Chong Yidong <cyd@stupidchicken.com>, rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Nonsensical byte compiler warning.
Date: 4 Apr 2007 22:08:55 +0200 [thread overview]
Message-ID: <20070404212752.GA2717@muc.de> (raw)
In-Reply-To: <873b3gpn4u.fsf@gmx.at>
Hi, Markus!
On Wed, Apr 04, 2007 at 10:19:45AM +0200, Markus Triska wrote:
> David Kastrup <dak@gnu.org> writes:
> > It points to c-end-of-defun, but the line number and described
> > called function are nonsensical.
> The line number is that of the first form of the function the
> questionable code is in. That makes sense, since the problem is in
> that function. It is *not* the call of char-before that's bogus. It's
> that its return value isn't used in the caller, c-end-of-defun. Any
> line of that function could contain the oversight. What line number
> would in your view make more sense to report?
As the current maintainer of cc-cmds.el, I haven't found this message at
all helpful. Here is the actual entry from my log of 2006-04-15, when I
first tried to crack the problem:
But I did get "While compiling c-end-of-defun in file
/home/acm/cc-mode-5.31.n/cc-cmds.el: ** `(char-after (1- (point)))' called for
effect". Track this down: It's in c-end-of-defun. By commenting out bits of
the function in a binary chop fashion, it's L1625, "(eq (char-before) ?\})".
I can't make head or tail of this. FIXME!!! POSTPONED.
It didn't occur to me at the time that char-after and char-before were
the same function.
> And yes, improving the optimiser to report `char-before' instead of
> `char-after' would be nice. I doubt that it would help anyone who
> can't find the problem with the current (quite good) message though.
As the "victim" of the situation, I would have found "char-before"
_exceptionally_ helpful. It might have urged me to look at the code more
carefully, rather than dismissing the message as a byte-compiler bug.
As I say, I don't find the current message helpful:
In c-end-of-defun:
cc-cmds.el:1612:4:Warning: value returned by `char-after' is not used
Taking the message bit by bit:
(i) "c-end-of-defun" _is_ helpful;
(ii) "1612:4" is positively unhelpful - at that location is "(interactive
"p")". Giving "1612:4" actively hinders debugging.
(iii) "char-after" doesn't exist in the source of c-end-of-defun;
(iv) The value returned by "char-before" _is_ used; it is explicitly
compared with "?\}".
I think this warning message is buggy. What it says ("value ... is not
used") is manifestly false - that value _is_ used; what isn't used is a
different value which is derived from that value.
What would a better message look like? I would suggest this:
In c-end-of-defun:
cc-cmds.el:1626:4:Warning: value returned from form is not used.
(where 1626 starts the `if' form, the most nested form for which the
warning holds). Or perhaps even better:
In c-end-of-defun:
cc-cmds.el:1647:57:Warning: value returned from form is not used.
Would it be easy to make this change to the byte compiler?
--
Alan Mackenzie (Ittersbach, Germany).
next prev parent reply other threads:[~2007-04-04 20:08 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-01 17:14 Nonsensical byte compiler warning David Kastrup
2007-04-01 18:10 ` Chong Yidong
2007-04-01 20:57 ` Alan Mackenzie
2007-04-02 12:29 ` Richard Stallman
2007-04-04 4:48 ` Markus Triska
2007-04-04 6:15 ` David Kastrup
2007-04-04 8:19 ` Markus Triska
2007-04-04 8:46 ` David Kastrup
2007-04-04 9:50 ` Markus Triska
2007-04-04 10:17 ` David Kastrup
2007-04-04 12:35 ` Markus Triska
2007-04-04 18:25 ` Markus Triska
2007-04-04 22:13 ` David Kastrup
2007-04-05 6:52 ` Richard Stallman
2007-04-05 7:55 ` Markus Triska
2007-04-06 12:56 ` Richard Stallman
2007-04-06 15:11 ` Chong Yidong
2007-04-08 20:47 ` Markus Triska
2007-04-09 15:42 ` Richard Stallman
2007-04-10 3:53 ` Glenn Morris
2007-04-10 17:27 ` Markus Triska
2007-04-11 4:00 ` Glenn Morris
2007-04-05 18:01 ` Chong Yidong
2007-04-04 20:08 ` Alan Mackenzie [this message]
2007-04-04 21:45 ` Markus Triska
2007-04-04 22:11 ` Chong Yidong
2007-04-05 5:44 ` Markus Triska
2007-04-08 1:21 ` Kim F. Storm
2007-04-08 11:27 ` Alan Mackenzie
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=20070404212752.GA2717@muc.de \
--to=acm@muc.de \
--cc=cyd@stupidchicken.com \
--cc=emacs-devel@gnu.org \
--cc=markus.triska@gmx.at \
--cc=rms@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.