From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Tue, 27 Nov 2018 21:39:12 -0800 Message-ID: <87zhtthibj.fsf@runbox.com> References: <20181125193050.GH27152@ACM> <2c2ae483-3309-f79d-07a5-30af1f49058b@cs.ucla.edu> <20181125212920.GK27152@ACM> <60ac9dfc-b540-89f9-68ea-ec7cceaa8511@cs.ucla.edu> <83in0kijz0.fsf@gnu.org> <9e216e61-7d95-94f0-cbee-593b4f32ced2@cs.ucla.edu> <20181126184359.GG4030@ACM> <55044caa-18fb-9e9a-81b4-3912f64d0aa4@cs.ucla.edu> <20181127074336.GA4705@ACM> <0ec5806a-0cc6-8b9f-6bc2-97875e36a511@cs.ucla.edu> <20181127211539.GB4705@ACM> <8c38f335-b25d-9ef6-110c-6efc4fda9d67@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1543383866 25310 195.159.176.226 (28 Nov 2018 05:44:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Nov 2018 05:44:26 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.90 (gnu/linux) Cc: cpitclaudel@gmail.com, Paul Eggert , michael_heerdegen@web.de, emacs-devel@gnu.org, Alan Mackenzie , Eli Zaretskii To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 28 06:44:22 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 1gRse5-0006TP-VC for ged-emacs-devel@m.gmane.org; Wed, 28 Nov 2018 06:44:22 +0100 Original-Received: from localhost ([::1]:46057 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRsgB-0001mU-VF for ged-emacs-devel@m.gmane.org; Wed, 28 Nov 2018 00:46:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRsZa-0004tP-34 for emacs-devel@gnu.org; Wed, 28 Nov 2018 00:39:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRsZW-0004hz-Lm for emacs-devel@gnu.org; Wed, 28 Nov 2018 00:39:41 -0500 Original-Received: from aibo.runbox.com ([91.220.196.211]:49154) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gRsZW-0004fI-BX; Wed, 28 Nov 2018 00:39:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=iNFcYzUsQnrqxdOYGC/CREQnw+biOf17zmolyiIr2vs=; b=Er4Qp1BDMpCKUc/jqYwRewzy+h HdGU9XvMXtifYL74XYpsvPqzRTuKkCYabyu0y38x0mYCXQ80f5OU4VSSuDu9D1riiJ2EL6q/5r+vX XK69Gh4WJJAiAU5h9HsdRZICCoxFWsqL/jyHcVQ9DJdZoG7XgLbpHWSdlRyetdW7yx/W3arNQfTcH 6AhqMrQe/4nzFfJH2uEoCp1GHl0s0ZNHpiF9QTdzen8/RaxNi1i3QleLuCjtcGELY1BRdJLl/uVaj d2m4uFzvs1y5WgzR2zu/7CFrLibWj+047h2ll9+qWJ6m26OiOomll3AR6iMW7CsUZxrsgCgmVcLpF 4ZC/nqOg==; Original-Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1gRsZQ-0006OI-7A; Wed, 28 Nov 2018 06:39:32 +0100 Original-Received: by mailfront12.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1gRsZ9-0002gs-IG; Wed, 28 Nov 2018 06:39:16 +0100 In-Reply-To: (Stefan Monnier's message of "Tue, 27 Nov 2018 17:09:15 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 91.220.196.211 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:231471 Archived-At: Stefan Monnier writes: > The main problem is for macro expansion: when we call a macro we can't > pass it these annotated sexps, so we have to de-annotate the sexp > arguments, which is both extra work and a loss of important info. > > So I was thinking of reducing the pain by re-using the edebug info so as > to find those arguments (or parts of arguments) which are treated as > normal expressions, which we don't need to de-annotate. The trouble with using the edebug info is that there's a lot of it that's wrong. I spent some time last year trying to get Emacs's test suite running under Testcover, which uses Edebug's instrumentation, and found a lot of incorrect Edebug specs. I reported maybe 30 of them, 8 are still on the buglist, and I have a list of about 50 files which if instrumented cause tests to fail, which are probably mostly Edebug spec bugs, but I haven't gone through the time-consuming process of tracking down and reporting them yet. And that's just in the approximately 1/3 of all the Lisp files in Emacs which get loaded by the test suite. But in thinking about this, I've had an idea for how it could work: What if the byte compiler first compiles as usual, and when it finds a function with warnings or errors it doesn't issue them immediately, but does another pass where it rereads the function (and maybe also any macros it uses which are defined in the same file) with Edebug or with Stefan's read-with-position + de-annotate, and compiles the result (throwing away the byte-compiled code from this pass), using the instrumentation/annotation to track source position. If it gets the same warnings/errors the second time, it can issue them with a more accurate position. If it gets a different warning or error on the second pass, that would indicate an Edebug spec problem. Unlike my Testcover project, broken Edebug specs wouldn't lead to broken code, because the byte compiler would always use the bytecode it made on the first pass. In this scheme, the only thing that gets slower is the byte-compilation of functions with warnings or errors.