all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Markus Triska <markus.triska@gmx.at>
Cc: acm@muc.de, Chong Yidong <cyd@stupidchicken.com>,
	rms@gnu.org, emacs-devel@gnu.org
Subject: Re: Nonsensical byte compiler warning.
Date: Wed, 04 Apr 2007 12:17:52 +0200	[thread overview]
Message-ID: <86bqi430kv.fsf@lola.quinscape.zz> (raw)
In-Reply-To: <877issii2y.fsf@gmx.at> (Markus Triska's message of "Wed\, 04 Apr 2007 11\:50\:45 +0200")

Markus Triska <markus.triska@gmx.at> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I reported this warning without being able to figure out where it
>> came from, remember?
>
> Yes, I remember. I also remember that at least 3 other people figured
> it out.

So I am not anyone, after all.

> One of them submitted a patch. Another one couldn't see the problem
> despite having pinpointed the exact location of the call (as you
> suggest that the optimiser report), believing in a "bug in the byte
> compiler".

Probably not anyone, either.

> While the error text can be improved, I find it unjustified to call
> the current behaviour "nonsensical", "plain useless" or "a compiler
> bug". It's a reasonable choice to point to the enclosing defun,

Not regarding the line number.  I disagree strongly.  The name of the
enclosing function is useful.  The line number isn't, except for
verifying that one is not looking at the wrong file.

But not even for that the reported number is really helpful since it
does not return the line number of the start or end of the defun
(which would give the user the clue that the line number is not
related to the point of error, but rather the function definition),
but rather a line in the function body that is somewhat close to the
actual beginning of the defun.

And that is worse than useless since it suggests that the line number
tries pinpointing some location inside of the function.  Which it
doesn't.

> and if your function has dozens of calls to char-before, there are
> probably graver problems to worry about.

So you are of the opinion that a function that calls any other
function from more than one place is a grave problem, and the byte
compiler is not supposed to be helpful with grave problems?

Sorry, but I can't see how one could consider your points and
conclusions here even remotely tenable.

-- 
David Kastrup

  reply	other threads:[~2007-04-04 10:17 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 [this message]
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
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=86bqi430kv.fsf@lola.quinscape.zz \
    --to=dak@gnu.org \
    --cc=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.