From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Sun, 2 Dec 2018 01:26:46 +0700 Message-ID: References: <20181129220552.GI12576@ACM> <9dde4ed7-8401-6022-a668-258d48bb7726@cs.ucla.edu> <20181130185503.GA16256@ACM> <20181130220218.GB16256@ACM> <138d56b7-53df-1ea5-377c-8502245f1b6b@cs.ucla.edu> <5C0239DA.4030907@gmx.at> <20181201124727.GC5102@ACM> <5C02962C.5040505@gmx.at> <20181201172127.GA29324@ACM> <7faee658-7ad0-4339-00e3-fef198a84121@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1543688706 4509 195.159.176.226 (1 Dec 2018 18:25:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2018 18:25:06 +0000 (UTC) Cc: Paul Eggert , Michael Heerdegen , Emacs developers , martin rudalics , Stefan Monnier , Alan Mackenzie , Eli Zaretskii To: =?UTF-8?Q?Cl=C3=A9ment_Pit=2DClaudel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 01 19:25:01 2018 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 1gT9wp-0000xN-T6 for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 19:25:00 +0100 Original-Received: from localhost ([::1]:42139 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT9yw-0002Vp-64 for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 13:27:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42546) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT9yo-0002Vj-PW for emacs-devel@gnu.org; Sat, 01 Dec 2018 13:27:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gT9yo-0001Pv-14 for emacs-devel@gnu.org; Sat, 01 Dec 2018 13:27:02 -0500 Original-Received: from mail-ot1-x336.google.com ([2607:f8b0:4864:20::336]:37991) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gT9ym-0001Pd-V3; Sat, 01 Dec 2018 13:27:01 -0500 Original-Received: by mail-ot1-x336.google.com with SMTP id e12so8134815otl.5; Sat, 01 Dec 2018 10:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PIIVNNv85okuF+ZXi6ZBDfDOIH9ZAGG3XOKJiyuy2A4=; b=fvIBkcGqnNdmxaoVPJejUO36VrDchZ9c7Pg+5P4gYOrG1Q6T2MTh/dCJ2BfzmRTUAj LuW6GtH5jEC2jemHcNbD1rw8GGyejX9sRYg/sY6lYoaBOasJqcBIzNxmmt9FjZnaC4T1 fbMZFxrV654UOrs5M0l5BXFQzJ9h7ijwZfS1oBth6vo8Sw1bCikMyxUJ5qZunIJqdA0E m2bgooecZSWwVONrJe0r8fbPcMOY6+POW8z8aJf4zGCZyT0hpqlIDirio6L4kJiV67BP Yzxng0afBZOfMwU2EMBya2yLXE3K329+YeMBUoz4LazPZp6+EbBsbC1V+zWCdrXOk2f6 Em9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PIIVNNv85okuF+ZXi6ZBDfDOIH9ZAGG3XOKJiyuy2A4=; b=l71Q+7vzdzi+hmV0ILbuyQOp+EwwsBiaRZun4sTaoqQeZ6mH/sYZF7d3Kfry4t5ZYr WV4fEAAKeepd569k4QXG2lomlAzzbON/3I3Fh+qk6vECHswxxxy8ezzzWkZrN3kOOcpJ 2T9Wj6f54ApRuzg9EAXG/NhtnOvaKrOcT6p/uMQ5Yvx5PyRjARJ0y/0CwZzAxg4sfoFH cLTR1TDUDuKlqK+gGlRNwYkFiSOlhfPISE4MBCyAPvO6MHCYAG+zp+or3wRivUUFGDF0 mnaCqz+Z+e3tS9yOa5IKpn+jrpc8STORpgQchL+dArVJN2fsXn+34gsCK+ABijtkBT5k 1GQw== X-Gm-Message-State: AA+aEWakosKAprKQLoc6+9GWSr+iUzbB57COP2C+G088LgbX47yPg698 IUM7V84SVb+eoyH/WRYgdCgwIPY4X7K0SmCQhcM= X-Google-Smtp-Source: AFSGD/XrGluODpIcNGlNlVGuVmdfDvmTyNtettbnMbmYC6IfjjuUXeuflc3TTZ8NbgrdHQugGN6D8Nixp42ISoJxBYU= X-Received: by 2002:a9d:401:: with SMTP id 1mr6255724otc.78.1543688820344; Sat, 01 Dec 2018 10:27:00 -0800 (PST) In-Reply-To: <7faee658-7ad0-4339-00e3-fef198a84121@gmail.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::336 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:231570 Archived-At: On Sun, Dec 2, 2018 at 12:51 AM Cl=C3=A9ment Pit-Claudel wrote: > IIUC, your code's strategy is to attach location info to symbols as they = are read; this is a clever trick, because macroexpansion tends to preserve = symbols more than it preserves conses (interestingly, Racket macros are giv= en syntax objects that include position information instead of raw SEXPs fo= r precisely this reason). But, again IIUC, attaching position information = on symbols means that they cannot be compared using pointer equality anymor= e, which means that EQ must get slower. I wonder: after byte-compiling and= reporting accurately-positioned warnings, couldn't we strip position infor= mation from symbols, so that usual Emacs execution isn't affected? The idea= would be to start by reading in symbols with position information, preserv= e this position information throughout byte-compilation, and then strip it = so that the rest of the code can use raw pointer equality. I am wondering about the same thing. The simplified view of the process would be: * Parse text into position-annotated AST * Analyze the position-annotated AST for errors and warnings, outputting accurate positions * Byte-compile position-annotated AST, stripping annotations in the process The complication is that parsing may invoke macros, some of which use =E2=80=98eq=E2=80=99 and cannot be recompiled to use =E2=80=98eq-with-posit= ion-information=E2=80=99. *If* that latter assumption is true, this complication could be solved by an opt-in property: A macro that has a 'position-aware property on it can be called directly on the position-annotated AST and expected to use =E2=80=98eq-with-position-information=E2=80=99; while a legacy macro= will be called on a de-annotated AST, may use plain =E2=80=98eq=E2=80=99, and will = return a similarly position-oblivious AST. The parser will then slap its best guess of position on the root of the macro=E2=80=99s output and say =E2=80= =9Cwell, I tried=E2=80=9D. This way, when people say =E2=80=9CI=E2=80=99m getting an incorrect warning= position=E2=80=9D, the first question will be =E2=80=9Cwhich macros do you use?=E2=80=9D, and = the second, =E2=80=9Chave they been updated to support source positions?=E2=80=9D Then = people will go ask those macros=E2=80=99 authors to update them, and/or write new position-aware implementations.