From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Sat, 01 Dec 2018 09:30:32 -0500 Message-ID: References: <23334086-c0a1-7b34-4234-343719618bd1@cs.ucla.edu> <20181128120443.GA4036@ACM> <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1543674569 5059 195.159.176.226 (1 Dec 2018 14:29:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Dec 2018 14:29:29 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: cpitclaudel@gmail.com, Paul Eggert , michael_heerdegen@web.de, emacs-devel@gnu.org, Alan Mackenzie , Eli Zaretskii To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 01 15:29:24 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 1gT6Gq-0001Cj-0S for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 15:29:24 +0100 Original-Received: from localhost ([::1]:41485 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT6Iw-0000Q8-7o for ged-emacs-devel@m.gmane.org; Sat, 01 Dec 2018 09:31:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45924) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT6IK-0000Q3-Iy for emacs-devel@gnu.org; Sat, 01 Dec 2018 09:30:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gT6IF-0007k6-IY for emacs-devel@gnu.org; Sat, 01 Dec 2018 09:30:56 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:45633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gT6IF-0007jb-EC; Sat, 01 Dec 2018 09:30:51 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id wB1EUWID019040; Sat, 1 Dec 2018 09:30:33 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 6A7A864D4F; Sat, 1 Dec 2018 09:30:32 -0500 (EST) In-Reply-To: <5C02962C.5040505@gmx.at> (martin rudalics's message of "Sat, 01 Dec 2018 15:09:48 +0100") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6430=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6430> : inlines <6975> : streams <1805869> : uri <2758591> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:231556 Archived-At: [ FWIW, my Helvetic origins want me to stay neutral on this issue. ] > Also I don't understand why it should be the byte compiler's task to > check the syntax of expressions for correctness. I can answer this part: it's simply because most of the work needed to perform such checks is already done by the compiler for other reasons, so it's easy to do it within the compiler. If you want to do it elsewhere, you'll need to either duplicate some of the compiler's code, or refactor it so it can be used for both. Refactoring is the ideal solution since it makes it possible to do yet more things (e.g. think of the Clang project as an example, compared to having it buried within LLVM), but it can be a lot of work. In any case, such a refactoring wouldn't make a difference to the problem at hand: the problem is not "the byte-compiler needs line numbers" but "the code that emits the warnings needs line numbers" and then how to make the line-information available to it and make this information survive through macro-expansion (even though the macros are not prepared to manipulate annotated source code). Stefan