From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: John Williams Newsgroups: gmane.emacs.devel Subject: Proposal: stack traces with line numbers Date: Sat, 14 Oct 2017 17:17:47 -0700 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1508031271 29384 195.159.176.226 (15 Oct 2017 01:34:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 15 Oct 2017 01:34:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 15 03:34:26 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 1e3Xoi-0005RF-U3 for ged-emacs-devel@m.gmane.org; Sun, 15 Oct 2017 03:34:13 +0200 Original-Received: from localhost ([::1]:55742 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3Xoq-0006Gj-Ft for ged-emacs-devel@m.gmane.org; Sat, 14 Oct 2017 21:34:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49561) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3Wd9-0003F6-H8 for emacs-devel@gnu.org; Sat, 14 Oct 2017 20:18:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3Wd8-00029w-6h for emacs-devel@gnu.org; Sat, 14 Oct 2017 20:18:11 -0400 Original-Received: from mail-wr0-x235.google.com ([2a00:1450:400c:c0c::235]:53906) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e3Wd7-00029f-VK for emacs-devel@gnu.org; Sat, 14 Oct 2017 20:18:10 -0400 Original-Received: by mail-wr0-x235.google.com with SMTP id y44so3157216wry.10 for ; Sat, 14 Oct 2017 17:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=zXb/Auisnu2o34uMJG6SugsXd/0Xbb9RApoWurVWh40=; b=vG8EWVSY/hA2mrpT2o1M4A7PrKtpU0U16NtI84RbtYzPGTgSjsvl1sHG1mu/vPcH2m kC0S1s0SKQgREXZYw+x1f6uxAQzlhvM4/9ngTjEVihmbBpLuwuYaPN2b4i0CgpNsKoAa 1TqMkoEmfuLXBTAp7mvbD+YNLvs6f2gThiaVo1Qt9PhnA8sHtL+cfYePZd6eN8c9XTsQ nIgkrUdka9BB59cyA042mUc8Lvz97zYNljBQPES4nUIe93/8o5DiXio2FvCtJgztVyK2 +32rdikQEqrh6+YIDb8vEl9MxqYTpt6PjCDQ9DSP4K8mAYkXeJNA/SMhv8ZFWkBKifMN TWNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=zXb/Auisnu2o34uMJG6SugsXd/0Xbb9RApoWurVWh40=; b=sZkELjAwtjuB7onInHiyJywhKZ+3NDufgEq9q+ZmuEX/SQ1U8WxWfxejMDVBmrAaxn EscMn7iRJmy9L4QE+UCSxi0o888jlgOeIsGXF6kK2pgT+/7mfBzAk5hqiUev6JHI54Ni 4l1H3J9aN8TLWQMt4cRKpNlS7vfdmRTqMSil4BOAsjE75jI3jlvhXT9DErZvNWkGPsC1 Texzp5EldDdx5uJsMYav0vEqxi3N8KaqKGSsymkHv78FHHY5aQ5kq+wlw2RCVTJJjaV9 CPbLFmOEKTs+5L24KOzn6zJomOYCZF1YOZ7RPaITNBTIY+M+BW6tJQgd3tklTniYfkJ3 K9aw== X-Gm-Message-State: AMCzsaWGY3iyJtTajgmM/VhqkWWroCwGI2gMG3efRPJ33U8LBFBv3Cfd M8Kz5vKs6QwjCjMV4HuPDNryxdFDZfnhjo0BGQq/CyWw X-Google-Smtp-Source: AOwi7QABl33iRm4xWPDrQsVI3rXDg+sZ1JAmKEJ4shEm/agcJjloLoOx+rrEmUy88aa1w2Wb5FQAERO53RM/BtVP9nM= X-Received: by 10.223.166.181 with SMTP id t50mr4509859wrc.251.1508026688257; Sat, 14 Oct 2017 17:18:08 -0700 (PDT) Original-Received: by 10.28.111.93 with HTTP; Sat, 14 Oct 2017 17:17:47 -0700 (PDT) X-Google-Sender-Auth: AErY2qGevhMRw0NhqQ_zozWSN04 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::235 X-Mailman-Approved-At: Sat, 14 Oct 2017 21:33:27 -0400 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:219537 Archived-At: Elisp is a fun language to work in, for the most part, but one thing I find very irritating compared to other languages is that there's no way to get a stack trace with line numbers. I'm wondering if others feel the same way and would be open to accepting a change to add better support for line numbers. Here's my plan: 1. Revise the reader to attach source references (i.e. filename, line number, and column number) to forms as they are read. 2. Update the byte compiler to preserve source references in compiled code. 3. Update the debugger to display source references in backtraces whenever possible. 4. Add a simple API for users to retrieve a stack trace suitable for writing to logs, etc. (There's already a stack trace API, but the information you can get from it isn't all that useful.) 5. Possibly add some facilities for macro authors to control the source refs in macro expansions. I'm not sure about that part because I believe most macros will propagate source information in a reasonable way simply by virtue of embedding their arguments in the expansions they generate. I already have a working proof of concept for the first part. What it does is attach a vector of (file name, line number, column number) to the head of each list as it is read. The information is "attached" using cons cells as keys in a weak-key hash table. I also added a little function to fetch data from the hash table so the representation is abstracted a little bit. Here's my rationale for the engineering decisions I've made so far: - I'm using a hash table because the other alternatives I looked at involved changing the representation of (some) cons cells, which doesn't sound so bad until you start looking at all the performance-critical code paths that would need to change, and all the parts of Emacs (e.g. the garbage collector) where the low-level representation of cons cells is handled as a special case. - I'm storing the information in vectors because it seems like a reasonably efficient use of memory. Certainly better than a list. It would be easy enough to encode all the relevant information in a string, but then the reader would be spending time building strings that will need to be decoded later, and I'm not sure it would help anyway, because each string would be unique, whereas with a vector, the same string object can be used for every reference in a file. Adding a new primitive type would also be an option, but it hardly seems worth the complexity to save a couple of words per source ref when 99% of them will probably only be retained long enough to byte-compile the code. - I'm saving line and column numbers rather that just byte/character offsets, because that's what developers need, and if it wasn't saved in that format, displaying a stack trace would involve opening the original source code to compute that information from the file contents. If I dropped the column numbers I could store a source ref in a cons cell rather than a vector, but it seems like a shame to throw away that kind of information when it's so easy to collect. (I could even pack the line and column number into a single integer, since I don't think it would be a big deal if there was an overflow for an incredibly large file, or a file with very long lines, but again, that seems like unnecessary complexity to me.) - I'm only attaching information to lists because only lists can be function calls, and attaching information to things like symbols would be problematic because every occurrence of a given symbol is represented by the same Lisp object. Of course some lists aren't function calls, but attaching a source ref to every list is a lot simpler and more reliable than trying to guess which lists are ultimately going to become function calls. - I'm only attaching information to the head of each list purely as a memory-saving measure. I can't think of scenario where you'd need a source reference for a list without having its head available, except maybe in the expansion of a macro that disassembles its arguments and puts them back together in a new list. If it's an issue in practice, I think a better solution would be for the macro expander to propagate source refs to every cons cell in a macro argument at the point where macro expansion takes place. Thoughts?