From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Date: Thu, 19 Mar 2020 20:34:49 +0000 Message-ID: <20200319203449.GA4180@ACM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="95077"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Rocky Bernstein , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 19 21:35:39 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jF1tD-000Odz-DR for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Mar 2020 21:35:39 +0100 Original-Received: from localhost ([::1]:42714 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jF1tC-0006s8-GJ for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Mar 2020 16:35:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39455) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jF1sV-0006GS-W1 for emacs-devel@gnu.org; Thu, 19 Mar 2020 16:34:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jF1sU-0005VO-JY for emacs-devel@gnu.org; Thu, 19 Mar 2020 16:34:55 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:30184 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jF1sU-0005UH-A2 for emacs-devel@gnu.org; Thu, 19 Mar 2020 16:34:54 -0400 Original-Received: (qmail 17140 invoked by uid 3782); 19 Mar 2020 20:34:52 -0000 Original-Received: from acm.muc.de (p4FE15C82.dip0.t-ipconnect.de [79.225.92.130]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 19 Mar 2020 21:34:49 +0100 Original-Received: (qmail 5142 invoked by uid 1000); 19 Mar 2020 20:34:49 -0000 Content-Disposition: inline In-Reply-To: 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.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245587 Archived-At: Hello, Stefan. On Thu, Mar 19, 2020 at 13:35:08 -0400, Stefan Monnier wrote: [ .... ] > It should be easy (much smaller than a summer project) to change the C > code so that a bytecode offset can be extracted from the backtrace. > The harder and more interesting part is how to propagate source > information (line numbers and/or lexical variable names and location) > to byte-code. There are many parts to this, so it's definitely > possible to get some summer project(s) out of it. E.g. one such > project is to change the reader so it outputs "fat cons cells" (i.e. > cons-cells with line-num info), then arrange for that info to survive > `macroexpand-all` and `cconv.el`. That could already be used to give > more precise line numbers in bytecompiler warnings. "More precise line numbers" is a misconstruction, even though I've used such language myself in the past. Line numbers don't come from a physical instrument which measures with, say +-1% accuracy. CORRECT line (and column) numbers are what we need. You will recall that the output of correct line/column numbers for byte compiler messages is a solved problem. I solved it and presented the fix in December 2018. This fix was rejected because it made Emacs slightly slower. In the 3½ years I've been grappling with this problem, I've tried all sorts of things like "fat cons cells". They don't work, and can't work. They can't work because large chunks of our software chew up and spit out cons cells with gay abandon (I'm talking about the byte compiler and things like cconv.el here). More to the point, users' macros chew up and spit out cons cells, and we have no control over them. So whilst we could, with a lot of tedious effort, clean up our own software to preserve cons cells (believe me, I've tried), this would fail in users' macros. Since then I've worked a fair bit on creating a "double" Emacs core, one core being for normal use, the other for byte compiling. There's a fair amount of work still to do on this, but I know how to do it. The problem is that I have been discouraged by the prospect of having this solution vetoed too, since it will make Emacs quite a bit bigger. I don't think it is fair to give this problem to a group of summer coders. It is too hard a problem, both technically and politically. [ .... ] > Stefan -- Alan Mackenzie (Nuremberg, Germany).