From: Alan Mackenzie <acm@muc.de>
To: emacs-devel@gnu.org
Subject: Getting the correct line/column numbers on byte compilation error/warning messages
Date: Sun, 16 Jul 2017 13:44:29 +0000 [thread overview]
Message-ID: <20170716134429.GA3013@acm> (raw)
Hello, Emacs.
The line/column numbers currently output by the byte compiler are not
rigorous - they sort of work most of the time. When they don't work, we
get bug #24449, or bug #2681, or bug #8774, or bug #9109, or bug #22288,
or bug #24128. Clearly a solution to this would be popular.
The reason for all these bugs is the mechanism in the byte compiler
where the reader stores the location of each occurrence of each symbol
in a list. "Each" time the byte compiler encounters a symbol, the
earlier occurrences of that symbol are discarded from the pertinent
list, leaving the location of the next element as the location for the
error/warning message. This is a "gross hack" which sometimes causes
the wrong line/column numbers to be output in error/warning messages.
I've been working on a replacement, and although I don't yet have
anything to show, I'd like to describe what I have.
I've modified lread.c so that when an enabling flag is set, it records
the source offset of each cons or vector in a hash table. The key to
the table is the cons cell/vector, and the value is the offset (more or
less). After each read operation, the "top structure" is recorded in
global variables, `read-outer-form' and `read-outer-loc'. (The latter
is non-nil when the former refers to the cdr of a dotted pair, or an
element of a vector.)
As the compilation proceeds recursively, `read-outer-form/loc' are bound
to successively more enclosed forms. Should an error or warning occur,
the line and column numbers are taken from these two variables via the
hash table.
This is all well and good. The implementation is problematic, largely
because currently, the compilation optimises by ripping the original
form apart and sticking it back together again in new conses. This
breaks the mechanism for accessing location information from the hash
table, whose keys are the original cons cells.
I've worked out some primitive functions which do what standard
functions do, but store their results in specified cons cells. For
example:
(defun bo-cons (kar kdr dest)
"Return a cons of KAR and KDR. This cons will be DEST, with its
car and cdr overwritten."
(setcar dest kar)
(setcdr dest kdr)
(setq bo-fixed t)
dest)
(The prefix "bo-" is at the moment purely for convenience, and the
variable `bo-fixed' is used to indicate change to a structure, because
the comparison (eq newform form) would now always return t.)
I've amended many of the functions in byte-opt.el to use only
cons-preserving primitives, though, as yet, I haven't tested them much.
What do people think?
--
Alan Mackenzie (Nuremberg, Germany).
next reply other threads:[~2017-07-16 13:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-16 13:44 Alan Mackenzie [this message]
2017-07-17 10:27 ` Getting the correct line/column numbers on byte compilation error/warning messages Clément Pit-Claudel
2017-07-17 17:53 ` Alan Mackenzie
2017-07-17 19:42 ` Stefan Monnier
2017-07-17 19:56 ` Alan Mackenzie
2017-07-17 20:27 ` Stefan Monnier
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=20170716134429.GA3013@acm \
--to=acm@muc.de \
--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.