From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Getting the correct line/column numbers on byte compilation error/warning messages Date: Sun, 16 Jul 2017 13:44:29 +0000 Message-ID: <20170716134429.GA3013@acm> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1500212801 2317 195.159.176.226 (16 Jul 2017 13:46:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Jul 2017 13:46:41 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 16 15:46:38 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dWjsa-0000Ng-S1 for ged-emacs-devel@m.gmane.org; Sun, 16 Jul 2017 15:46:36 +0200 Original-Received: from localhost ([::1]:45325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dWjsf-0001HD-RJ for ged-emacs-devel@m.gmane.org; Sun, 16 Jul 2017 09:46:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dWjru-0001Gw-G7 for emacs-devel@gnu.org; Sun, 16 Jul 2017 09:45:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dWjrq-0002TW-Jb for emacs-devel@gnu.org; Sun, 16 Jul 2017 09:45:54 -0400 Original-Received: from ocolin.muc.de ([193.149.48.4]:38583 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1dWjrq-0002SD-7T for emacs-devel@gnu.org; Sun, 16 Jul 2017 09:45:50 -0400 Original-Received: (qmail 28409 invoked by uid 3782); 16 Jul 2017 13:45:47 -0000 Original-Received: from acm.muc.de (p548C72C7.dip0.t-ipconnect.de [84.140.114.199]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 16 Jul 2017 15:45:46 +0200 Original-Received: (qmail 3142 invoked by uid 1000); 16 Jul 2017 13:44:29 -0000 Content-Disposition: inline X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:216723 Archived-At: 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).