From unknown Mon Jun 23 04:09:37 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#19206 <19206@debbugs.gnu.org> To: bug#19206 <19206@debbugs.gnu.org> Subject: Status: 25.0.50; CC Mode tracks wrong source files Reply-To: bug#19206 <19206@debbugs.gnu.org> Date: Mon, 23 Jun 2025 11:09:37 +0000 retitle 19206 25.0.50; CC Mode tracks wrong source files reassign 19206 emacs,cc-mode submitter 19206 Sebastian Wiesner severity 19206 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 28 05:20:58 2014 Received: (at submit) by debbugs.gnu.org; 28 Nov 2014 10:20:58 +0000 Received: from localhost ([127.0.0.1]:48107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XuIfZ-0004Lh-OR for submit@debbugs.gnu.org; Fri, 28 Nov 2014 05:20:58 -0500 Received: from eggs.gnu.org ([208.118.235.92]:39204) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XuIfX-0004LZ-6K for submit@debbugs.gnu.org; Fri, 28 Nov 2014 05:20:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuIfS-0004ak-7Q for submit@debbugs.gnu.org; Fri, 28 Nov 2014 05:20:54 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=BAYES_50,RAZOR2_CHECK autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:33300) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuIfS-0004ag-3t for submit@debbugs.gnu.org; Fri, 28 Nov 2014 05:20:50 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuIfN-0006lA-LV for bug-gnu-emacs@gnu.org; Fri, 28 Nov 2014 05:20:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuIfJ-0004aM-6n for bug-gnu-emacs@gnu.org; Fri, 28 Nov 2014 05:20:45 -0500 Received: from vega.uberspace.de ([95.143.172.245]:43000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuIfI-0004XO-LM for bug-gnu-emacs@gnu.org; Fri, 28 Nov 2014 05:20:41 -0500 Received: (qmail 23609 invoked from network); 28 Nov 2014 10:20:38 -0000 Received: from localhost (HELO lunaryorn-air.fritz.box) (127.0.0.1) by vega.uberspace.de with SMTP; 28 Nov 2014 10:20:38 -0000 From: Sebastian Wiesner To: bug-gnu-emacs@gnu.org Subject: 25.0.50; CC Mode tracks wrong source files Date: Fri, 28 Nov 2014 11:19:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) CC Mode tracks wrong source files when a CC Mode derived mode is installed non-interactively. To reproduce, save the following code as `cc-miscompile.el' (require 'package) (require 'cc-defs) (defun main () (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/")) (setq package-user-dir (make-temp-file "cc-miscompile" 'directory)) (package-initialize) (package-refresh-contents) (package-install 'd-mode) (require 'd-mode) (let ((source (get (intern "c-typedef-decl-kwds" c-lang-constants) 'sourc= e))) (message "Sources: %S" (mapcar 'car source))) (delete-directory package-user-dir 'recursive)) (main) and run it with `emacs -Q --script cc-miscompile.el'. The output is as follows (package.el output shortened for readility): Contacting host: melpa.org:80 Contacting host: elpa.gnu.org:80 [=E2=80=A6] Sources: (d-mode cc-miscompile cc-langs) Note that `cc-miscompile' ends up in the source list of `c-typedef-decl-kwds', even though it never actually calls any `c-*' functions at all. Naturally, CC Mode will later try to load this file, and fail if it is not in the `load-path'. This effectively breaks installations of D Mode from non-interactive Emacs sessions. I did not try to find the culprit. The CC Mode code is convoluted beyond my understanding. From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 28 14:49:14 2014 Received: (at 19206) by debbugs.gnu.org; 28 Nov 2014 19:49:14 +0000 Received: from localhost ([127.0.0.1]:48676 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XuRXV-0003eU-Mc for submit@debbugs.gnu.org; Fri, 28 Nov 2014 14:49:14 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:41390) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XuRXR-0003eB-Rg for 19206@debbugs.gnu.org; Fri, 28 Nov 2014 14:49:10 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id sASJn7o6027819; Fri, 28 Nov 2014 14:49:08 -0500 Received: by pastel.home (Postfix, from userid 20848) id 387883EB6; Fri, 28 Nov 2014 14:49:07 -0500 (EST) From: Stefan Monnier To: Sebastian Wiesner Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files Message-ID: References: Date: Fri, 28 Nov 2014 14:49:07 -0500 In-Reply-To: (Sebastian Wiesner's message of "Fri, 28 Nov 2014 11:19:01 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5139=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5139> : inlines <1569> : streams <1350042> : uri <1836510> X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 19206 Cc: 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > I did not try to find the culprit. The CC Mode code is convoluted > beyond my understanding. Agreed, it's madness. I'd like to streamline it (at some runtime cost), but that requires major modes that use CC to do (require 'cc-langs) rather than (eval-when-compile (require 'cc-langs)) Still, you can already do that and I recommend it since it should reduce the number of ways the code can fail. More to the point, it might fix the problem you're experiencing (maybe cc-miscompile will still be mentioned in there, but it hopefully won't be any more). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 28 17:25:47 2014 Received: (at 19206) by debbugs.gnu.org; 28 Nov 2014 22:25:47 +0000 Received: from localhost ([127.0.0.1]:48715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XuTz1-0007eM-Ap for submit@debbugs.gnu.org; Fri, 28 Nov 2014 17:25:47 -0500 Received: from colin.muc.de ([193.149.48.1]:19476 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XuTyx-0007e8-QI for 19206@debbugs.gnu.org; Fri, 28 Nov 2014 17:25:45 -0500 Received: (qmail 60511 invoked by uid 3782); 28 Nov 2014 22:25:42 -0000 Date: 28 Nov 2014 22:25:42 -0000 Message-ID: <20141128222542.60510.qmail@mail.muc.de> From: Alan Mackenzie To: Sebastian Wiesner Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files Organization: muc.de e.V. In-Reply-To: X-Newsgroups: gnu.emacs.bug User-Agent: tin/2.2.0-20131224 ("Lochindaal") (UNIX) (FreeBSD/8.4-RELEASE (amd64)) X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19206 Cc: 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hello, Sebastian. In article you wrote: > CC Mode tracks wrong source files when a CC Mode derived mode is > installed non-interactively. The rest of your post describes your detective work to track down the problem, which is brilliant. But you haven't said what the problem itself is, at least not in high level terms. What does the file look like which does the non-interactive installation, when do you see an error, and what is this error message? > To reproduce, save the following code as `cc-miscompile.el' > (require 'package) > (require 'cc-defs) > (defun main () > (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/")) > (setq package-user-dir (make-temp-file "cc-miscompile" 'directory)) > (package-initialize) > (package-refresh-contents) > (package-install 'd-mode) > (require 'd-mode) > (let ((source (get (intern "c-typedef-decl-kwds" c-lang-constants) 'source))) > (message "Sources: %S" (mapcar 'car source))) > (delete-directory package-user-dir 'recursive)) > (main) > and run it with `emacs -Q --script cc-miscompile.el'. The output is as > follows (package.el output shortened for readility): > Contacting host: melpa.org:80 > Contacting host: elpa.gnu.org:80 > [?] > Sources: (d-mode cc-miscompile cc-langs) > Note that `cc-miscompile' ends up in the source list of > `c-typedef-decl-kwds', even though it never actually calls any `c-*' > functions at all. The byte compilation of d-mode.el is being done during the loading of cc-miscompile.el. This somewhat unusual constellation, I think, is causing the problem. When CC Mode determines the file name to put onto a c-lang-defconst's 'source property, it gives priority to the load file name, and only when this is nil does it use the byte-compile file name. (This is in defsubst c-get-current-file in cc-defs.el). It would seem this is not the correct priority. I think swapping the first two arms of the `cond' form in c-get-current-file may solve the problem. It's a bit late to try this tonight, I'll try it tomorrow. > Naturally, CC Mode will later try to load this file, and fail if it is > not in the `load-path'. This effectively breaks installations of D > Mode from non-interactive Emacs sessions. > I did not try to find the culprit. The CC Mode code is convoluted > beyond my understanding. The mechanism for the c-lang-defvar's may appear complicated, but it this concentration of the complexity in a single place that enables the simple, tabular definition of language dependent constants, even (especially) in derived modes. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 28 17:37:55 2014 Received: (at 19206) by debbugs.gnu.org; 28 Nov 2014 22:37:55 +0000 Received: from localhost ([127.0.0.1]:48720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XuUAk-000831-ML for submit@debbugs.gnu.org; Fri, 28 Nov 2014 17:37:55 -0500 Received: from vega.uberspace.de ([95.143.172.245]:40529) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XuUAi-00082p-Iq for 19206@debbugs.gnu.org; Fri, 28 Nov 2014 17:37:53 -0500 Received: (qmail 2777 invoked from network); 28 Nov 2014 22:37:50 -0000 Received: from localhost (HELO lunaryorn-air.fritz.box) (127.0.0.1) by vega.uberspace.de with SMTP; 28 Nov 2014 22:37:50 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files From: Sebastian Wiesner In-Reply-To: <20141128222542.60510.qmail@mail.muc.de> Date: Fri, 28 Nov 2014 23:37:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <77ED0F7F-BCB0-45E9-9E06-76914339FF4D@lunaryorn.com> References: <20141128222542.60510.qmail@mail.muc.de> To: Alan Mackenzie X-Mailer: Apple Mail (2.1993) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19206 Cc: 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Am 28.11.2014 um 23:25 schrieb Alan Mackenzie : >=20 > Hello, Sebastian. > In article you = wrote: >> CC Mode tracks wrong source files when a CC Mode derived mode is >> installed non-interactively. >=20 > The rest of your post describes your detective work to track down the > problem, which is brilliant. But you haven't said what the problem = itself > is, at least not in high level terms. >=20 > What does the file look like which does the non-interactive = installation, > when do you see an error, and what is this error message? The =E2=80=9Cfile=E2=80=9D that does the non-interactive installation is = Cask from https://github.com/cask/cask/. =20 I use Cask to install packages into per-project directories, and to run = ERT test suites for Emacs Lisp in these =E2=80=9Cper-project=E2=80=9D = package environments. The error occurs when a test case tries to enable D Mode. It's a = standard load file error, pointing to the main script of Cask. This seems all rather irrelevant to me, though. The sample code = demonstrates the issue quite clearly. >> I did not try to find the culprit. The CC Mode code is convoluted >> beyond my understanding. >=20 > The mechanism for the c-lang-defvar's may appear complicated, but it = this > concentration of the complexity in a single place that enables the = simple, > tabular definition of language dependent constants, even (especially) = in > derived modes. Well, if you say. I'm curious, though, what this system would enable me = to do, that an ordinary `require' could not? Greetings, Sebastian= From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 30 13:42:57 2014 Received: (at 19206) by debbugs.gnu.org; 30 Nov 2014 18:42:57 +0000 Received: from localhost ([127.0.0.1]:50110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xv9SS-0001X3-Jj for submit@debbugs.gnu.org; Sun, 30 Nov 2014 13:42:57 -0500 Received: from colin.muc.de ([193.149.48.1]:34518 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xv9SO-0001Wr-Cy for 19206@debbugs.gnu.org; Sun, 30 Nov 2014 13:42:54 -0500 Received: (qmail 12851 invoked by uid 3782); 30 Nov 2014 18:42:51 -0000 Received: from acm.muc.de (pD951B3FA.dip0.t-ipconnect.de [217.81.179.250]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 30 Nov 2014 19:42:49 +0100 Received: (qmail 13023 invoked by uid 1000); 30 Nov 2014 18:42:21 -0000 Date: Sun, 30 Nov 2014 18:42:21 +0000 To: Sebastian Wiesner Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files Message-ID: <20141130184221.GA12974@acm.acm> References: <20141128222542.60510.qmail@mail.muc.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141128222542.60510.qmail@mail.muc.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19206 Cc: 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hello, again, Sebastian. On Fri, Nov 28, 2014 at 10:25:42PM -0000, Alan Mackenzie wrote: > Hello, Sebastian. > In article you wrote: > > CC Mode tracks wrong source files when a CC Mode derived mode is > > installed non-interactively. > > To reproduce, save the following code as `cc-miscompile.el' > > (require 'package) > > (require 'cc-defs) > > (defun main () > > (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/")) > > (setq package-user-dir (make-temp-file "cc-miscompile" 'directory)) > > (package-initialize) > > (package-refresh-contents) > > (package-install 'd-mode) > > (require 'd-mode) > > (let ((source (get (intern "c-typedef-decl-kwds" c-lang-constants) 'source))) > > (message "Sources: %S" (mapcar 'car source))) > > (delete-directory package-user-dir 'recursive)) > > (main) > > and run it with `emacs -Q --script cc-miscompile.el'. The output is as > > follows (package.el output shortened for readility): > > Contacting host: melpa.org:80 > > Contacting host: elpa.gnu.org:80 > > [?] > > Sources: (d-mode cc-miscompile cc-langs) > > Note that `cc-miscompile' ends up in the source list of > > `c-typedef-decl-kwds', even though it never actually calls any `c-*' > > functions at all. OK. The problem was that CC Mode was using the flag `load-in-progress' to assume that a CC Mode file was being loaded, for example by a `require' form inside a compilation of another CC Mode file. This assumption breaks down when another file, such as cc-miscompile.el, while loading, initiates compilation of a CC Mode derivative. > The byte compilation of d-mode.el is being done during the loading of > cc-miscompile.el. This somewhat unusual constellation, I think, is > causing the problem. When CC Mode determines the file name to put onto > a c-lang-defconst's 'source property, it gives priority to the load file > name, and only when this is nil does it use the byte-compile file name. > (This is in defsubst c-get-current-file in cc-defs.el). It would seem > this is not the correct priority. > I think swapping the first two arms of the `cond' form in > c-get-current-file may solve the problem. It's a bit late to try this > tonight, I'll try it tomorrow. No, that wouldn't work. What I've implemented is when both loading and byte-compilation are active at the same time, CC Mode walks down the lisp stack to discover which one of them is actually active. > > Naturally, CC Mode will later try to load this file, and fail if it is > > not in the `load-path'. This effectively breaks installations of D > > Mode from non-interactive Emacs sessions. Please try the following patch, which seems to work in the test case you supplied, in the real situation, and let me know how well it works. The d-mode.elc produced can be successfully loaded into the Emacs that built it. Thanks for the bug report, and thanks especially for doing so much of the preliminary detective work. diff --git a/lisp/progmodes/cc-bytecomp.el b/lisp/progmodes/cc-bytecomp.el index 1936627..bd2fd34 100644 --- a/lisp/progmodes/cc-bytecomp.el +++ b/lisp/progmodes/cc-bytecomp.el @@ -84,13 +84,60 @@ ;;`(message ,@args) ) +(defun cc-bytecomp-compiling-or-loading () + ;; Return whether byte-compilation or loading is currently active, + ;; returning 'compiling or 'loading or nil. + ;; If both are active, the "innermost" activity counts. Note that + ;; compilation can trigger loading (various `require' type forms) + ;; and loading can trigger compilation (the package manager does + ;; this). We walk the lisp stack if necessary. + (cond + ((and load-in-progress + (boundp 'byte-compile-dest-file) + (stringp byte-compile-dest-file)) + (let ((n 0) elt) + (while (and + (setq elt (backtrace-frame n)) + (not (and (car elt) + (memq (cadr elt) + '(load byte-compile-file + byte-recompile-directory + batch-byte-compile))))) + (setq n (1+ n))) + (cond + ((eq (cadr elt) 'load) + 'loading) + ((memq (cadr elt) '(byte-compile-file + byte-recompile-directory + batch-byte-compile)) + 'compiling) + (t ; Can't happen. + (message "cc-bytecomp-compiling-or-loading: System flags spuriously set") + nil)))) + (load-in-progress + ;; Being loaded. + 'loading) + ((and (boundp 'byte-compile-dest-file) + (stringp byte-compile-dest-file)) + ;; Being compiled. + 'compiling) + (t + ;; Being evaluated interactively. + nil))) + +(defsubst cc-bytecomp-is-compiling () + "Return non-nil if eval'ed during compilation." + (eq (cc-bytecomp-compiling-or-loading) 'compiling)) + +(defsubst cc-bytecomp-is-loading () + "Return non-nil if eval'ed during loading. +Nil will be returned if we're in a compilation triggered by the loading." + (eq (cc-bytecomp-compiling-or-loading) 'loading)) + (defun cc-bytecomp-setup-environment () ;; Eval'ed during compilation to setup variables, functions etc ;; declared with `cc-bytecomp-defvar' et al. - (if (not load-in-progress) - ;; Look at `load-in-progress' to tell whether we're called - ;; directly in the file being compiled or just from some file - ;; being loaded during compilation. + (if (not (cc-bytecomp-is-loading)) (let (p) (if cc-bytecomp-environment-set (error "Byte compilation environment already set - \ @@ -138,7 +185,7 @@ perhaps a `cc-bytecomp-restore-environment' is forgotten somewhere")) (defun cc-bytecomp-restore-environment () ;; Eval'ed during compilation to restore variables, functions etc ;; declared with `cc-bytecomp-defvar' et al. - (if (not load-in-progress) + (if (not (cc-bytecomp-is-loading)) (let (p) (setq p cc-bytecomp-unbound-variables) (while p @@ -282,9 +329,7 @@ use within `eval-when-compile'." `(eval-when-compile (if (and (fboundp 'cc-bytecomp-is-compiling) (cc-bytecomp-is-compiling)) - (if (or (not load-in-progress) - (not (featurep ,cc-part))) - (cc-bytecomp-load (symbol-name ,cc-part))) + (cc-bytecomp-load (symbol-name ,cc-part)) (require ,cc-part)))) (defmacro cc-external-require (feature) @@ -296,12 +341,6 @@ afterwards. Don't use within `eval-when-compile'." (require ,feature) (eval-when-compile (cc-bytecomp-setup-environment)))) -(defun cc-bytecomp-is-compiling () - "Return non-nil if eval'ed during compilation. Don't use outside -`eval-when-compile'." - (and (boundp 'byte-compile-dest-file) - (stringp byte-compile-dest-file))) - (defmacro cc-bytecomp-defvar (var) "Binds the symbol as a variable during compilation of the file, to silence the byte compiler. Don't use within `eval-when-compile'." @@ -315,8 +354,7 @@ to silence the byte compiler. Don't use within `eval-when-compile'." "cc-bytecomp-defvar: Saving %s (as unbound)" ',var) (setq cc-bytecomp-unbound-variables (cons ',var cc-bytecomp-unbound-variables)))) - (if (and (cc-bytecomp-is-compiling) - (not load-in-progress)) + (if (cc-bytecomp-is-compiling) (progn (defvar ,var) (set ',var (intern (concat "cc-bytecomp-ignore-var:" @@ -344,8 +382,7 @@ at compile time, e.g. for macros and inline functions." (setq cc-bytecomp-original-functions (cons (list ',fun nil 'unbound) cc-bytecomp-original-functions)))) - (if (and (cc-bytecomp-is-compiling) - (not load-in-progress)) + (if (cc-bytecomp-is-compiling) (progn (fset ',fun (intern (concat "cc-bytecomp-ignore-fun:" (symbol-name ',fun)))) diff --git a/lisp/progmodes/cc-defs.el b/lisp/progmodes/cc-defs.el index 1d8b8ab..b0e83f3 100644 --- a/lisp/progmodes/cc-defs.el +++ b/lisp/progmodes/cc-defs.el @@ -1823,19 +1823,22 @@ system." (defvar c-lang-const-expansion nil) +;; Ugly hack to pull in the definition of `cc-bytecomp-compiling-or-loading` +;; from cc-bytecomp to make it available at loadtime. This is the same +;; mechanism used in cc-mode.el for `c-populate-syntax-table'. +(defalias 'cc-bytecomp-compiling-or-loading + (cc-eval-when-compile + (let ((f (symbol-function 'cc-bytecomp-compiling-or-loading))) + (if (byte-code-function-p f) f (byte-compile f))))) + (defsubst c-get-current-file () ;; Return the base name of the current file. - (let ((file (cond - (load-in-progress - ;; Being loaded. - load-file-name) - ((and (boundp 'byte-compile-dest-file) - (stringp byte-compile-dest-file)) - ;; Being compiled. - byte-compile-dest-file) - (t - ;; Being evaluated interactively. - (buffer-file-name))))) + (let* ((c-or-l (cc-bytecomp-compiling-or-loading)) + (file + (cond + ((eq c-or-l 'loading) load-file-name) + ((eq c-or-l 'compiling) byte-compile-dest-file) + ((null c-or-l) (buffer-file-name))))) (and file (file-name-sans-extension (file-name-nondirectory file))))) @@ -2073,9 +2076,7 @@ quoted." (if (or (eq c-lang-const-expansion 'call) (and (not c-lang-const-expansion) (not mode)) - load-in-progress - (not (boundp 'byte-compile-dest-file)) - (not (stringp byte-compile-dest-file))) + (not (cc-bytecomp-is-compiling))) ;; Either a straight call is requested in the context, or ;; we're in an "uncontrolled" context and got no language, ;; or we're not being byte compiled so the compile time diff --git a/lisp/progmodes/cc-langs.el b/lisp/progmodes/cc-langs.el index 68b2d62..22d78b5 100644 --- a/lisp/progmodes/cc-langs.el +++ b/lisp/progmodes/cc-langs.el @@ -3252,10 +3252,7 @@ function it returns is byte compiled with all the evaluated results from the language constants. Use the `c-init-language-vars' macro to accomplish that conveniently." - (if (and (not load-in-progress) - (boundp 'byte-compile-dest-file) - (stringp byte-compile-dest-file)) - + (if (cc-bytecomp-is-compiling) ;; No need to byte compile this lambda since the byte compiler is ;; smart enough to detect the `funcall' construct in the ;; `c-init-language-vars' macro below and compile it all straight -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 02 06:03:29 2014 Received: (at 19206) by debbugs.gnu.org; 2 Dec 2014 11:03:29 +0000 Received: from localhost ([127.0.0.1]:51446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XvlEu-00030S-8K for submit@debbugs.gnu.org; Tue, 02 Dec 2014 06:03:29 -0500 Received: from vega.uberspace.de ([95.143.172.245]:41713) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XvlEr-00030I-4r for 19206@debbugs.gnu.org; Tue, 02 Dec 2014 06:03:26 -0500 Received: (qmail 21172 invoked from network); 2 Dec 2014 11:03:23 -0000 Received: from localhost (HELO lunaryorn-air.fritz.box) (127.0.0.1) by vega.uberspace.de with SMTP; 2 Dec 2014 11:03:23 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files From: Sebastian Wiesner In-Reply-To: <20141130184221.GA12974@acm.acm> Date: Tue, 2 Dec 2014 12:03:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C8C5538-BC19-4094-832C-3F3259DE37A5@lunaryorn.com> References: <20141128222542.60510.qmail@mail.muc.de> <20141130184221.GA12974@acm.acm> To: Alan Mackenzie X-Mailer: Apple Mail (2.1993) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 19206 Cc: 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) > Am 30.11.2014 um 19:42 schrieb Alan Mackenzie : >=20 > Hello, again, Sebastian. >=20 > On Fri, Nov 28, 2014 at 10:25:42PM -0000, Alan Mackenzie wrote: >> Hello, Sebastian. >> In article you = wrote: >>> CC Mode tracks wrong source files when a CC Mode derived mode is >>> installed non-interactively. >=20 >>> To reproduce, save the following code as `cc-miscompile.el' >=20 >>> (require 'package) >>> (require 'cc-defs) >=20 >>> (defun main () >>> (add-to-list 'package-archives '("melpa" . = "http://melpa.org/packages/")) >=20 >>> (setq package-user-dir (make-temp-file "cc-miscompile" 'directory)) >=20 >>> (package-initialize) >>> (package-refresh-contents) >>> (package-install 'd-mode) >=20 >>> (require 'd-mode) >=20 >>> (let ((source (get (intern "c-typedef-decl-kwds" c-lang-constants) = 'source))) >>> (message "Sources: %S" (mapcar 'car source))) >=20 >>> (delete-directory package-user-dir 'recursive)) >=20 >>> (main) >=20 >>> and run it with `emacs -Q --script cc-miscompile.el'. The output is = as >>> follows (package.el output shortened for readility): >=20 >>> Contacting host: melpa.org:80 >>> Contacting host: elpa.gnu.org:80 >>> [?] >>> Sources: (d-mode cc-miscompile cc-langs) >=20 >>> Note that `cc-miscompile' ends up in the source list of >>> `c-typedef-decl-kwds', even though it never actually calls any `c-*' >>> functions at all. >=20 > OK. The problem was that CC Mode was using the flag = `load-in-progress' > to assume that a CC Mode file was being loaded, for example by a > `require' form inside a compilation of another CC Mode file. This > assumption breaks down when another file, such as cc-miscompile.el, > while loading, initiates compilation of a CC Mode derivative. >=20 >> The byte compilation of d-mode.el is being done during the loading of >> cc-miscompile.el. This somewhat unusual constellation, I think, is >> causing the problem. When CC Mode determines the file name to put = onto >> a c-lang-defconst's 'source property, it gives priority to the load = file >> name, and only when this is nil does it use the byte-compile file = name. >> (This is in defsubst c-get-current-file in cc-defs.el). It would = seem >> this is not the correct priority. >=20 >> I think swapping the first two arms of the `cond' form in >> c-get-current-file may solve the problem. It's a bit late to try = this >> tonight, I'll try it tomorrow. >=20 > No, that wouldn't work. What I've implemented is when both loading = and > byte-compilation are active at the same time, CC Mode walks down the > lisp stack to discover which one of them is actually active. Well, if you say=E2=80=A6 I find this =E2=80=9Csolution=E2=80=9D = horrifying, but I am probably just unable to appreciate the full = complexity of this issue. >>> Naturally, CC Mode will later try to load this file, and fail if it = is >>> not in the `load-path'. This effectively breaks installations of D >>> Mode from non-interactive Emacs sessions. >=20 > Please try the following patch, which seems to work in the test case = you > supplied, in the real situation, and let me know how well it works. = The > d-mode.elc produced can be successfully loaded into the Emacs that = built > it. Do I need to build a patched Emacs to try it? > diff --git a/lisp/progmodes/cc-bytecomp.el = b/lisp/progmodes/cc-bytecomp.el > index 1936627..bd2fd34 100644 > --- a/lisp/progmodes/cc-bytecomp.el > +++ b/lisp/progmodes/cc-bytecomp.el > @@ -84,13 +84,60 @@ > ;;`(message ,@args) > ) >=20 > +(defun cc-bytecomp-compiling-or-loading () > + ;; Return whether byte-compilation or loading is currently active, > + ;; returning 'compiling or 'loading or nil. > + ;; If both are active, the "innermost" activity counts. Note that > + ;; compilation can trigger loading (various `require' type forms) > + ;; and loading can trigger compilation (the package manager does > + ;; this). We walk the lisp stack if necessary. > + (cond > + ((and load-in-progress > + (boundp 'byte-compile-dest-file) > + (stringp byte-compile-dest-file)) > + (let ((n 0) elt) > + (while (and > + (setq elt (backtrace-frame n)) > + (not (and (car elt) > + (memq (cadr elt) > + '(load byte-compile-file > + byte-recompile-directory > + batch-byte-compile))))) > + (setq n (1+ n))) > + (cond > + ((eq (cadr elt) 'load) > + 'loading) > + ((memq (cadr elt) '(byte-compile-file > + byte-recompile-directory > + batch-byte-compile)) > + 'compiling) > + (t ; Can't happen. > + (message "cc-bytecomp-compiling-or-loading: System flags = spuriously set") > + nil)))) > + (load-in-progress > + ;; Being loaded. > + 'loading) > + ((and (boundp 'byte-compile-dest-file) > + (stringp byte-compile-dest-file)) > + ;; Being compiled. > + 'compiling) > + (t > + ;; Being evaluated interactively. > + nil))) > + > +(defsubst cc-bytecomp-is-compiling () > + "Return non-nil if eval'ed during compilation." > + (eq (cc-bytecomp-compiling-or-loading) 'compiling)) > + > +(defsubst cc-bytecomp-is-loading () > + "Return non-nil if eval'ed during loading. > +Nil will be returned if we're in a compilation triggered by the = loading." > + (eq (cc-bytecomp-compiling-or-loading) 'loading)) > + > (defun cc-bytecomp-setup-environment () > ;; Eval'ed during compilation to setup variables, functions etc > ;; declared with `cc-bytecomp-defvar' et al. > - (if (not load-in-progress) > - ;; Look at `load-in-progress' to tell whether we're called > - ;; directly in the file being compiled or just from some file > - ;; being loaded during compilation. > + (if (not (cc-bytecomp-is-loading)) > (let (p) > (if cc-bytecomp-environment-set > (error "Byte compilation environment already set - \ > @@ -138,7 +185,7 @@ perhaps a `cc-bytecomp-restore-environment' is = forgotten somewhere")) > (defun cc-bytecomp-restore-environment () > ;; Eval'ed during compilation to restore variables, functions etc > ;; declared with `cc-bytecomp-defvar' et al. > - (if (not load-in-progress) > + (if (not (cc-bytecomp-is-loading)) > (let (p) > (setq p cc-bytecomp-unbound-variables) > (while p > @@ -282,9 +329,7 @@ use within `eval-when-compile'." > `(eval-when-compile > (if (and (fboundp 'cc-bytecomp-is-compiling) > (cc-bytecomp-is-compiling)) > - (if (or (not load-in-progress) > - (not (featurep ,cc-part))) > - (cc-bytecomp-load (symbol-name ,cc-part))) > + (cc-bytecomp-load (symbol-name ,cc-part)) > (require ,cc-part)))) >=20 > (defmacro cc-external-require (feature) > @@ -296,12 +341,6 @@ afterwards. Don't use within = `eval-when-compile'." > (require ,feature) > (eval-when-compile (cc-bytecomp-setup-environment)))) >=20 > -(defun cc-bytecomp-is-compiling () > - "Return non-nil if eval'ed during compilation. Don't use outside > -`eval-when-compile'." > - (and (boundp 'byte-compile-dest-file) > - (stringp byte-compile-dest-file))) > - > (defmacro cc-bytecomp-defvar (var) > "Binds the symbol as a variable during compilation of the file, > to silence the byte compiler. Don't use within `eval-when-compile'." > @@ -315,8 +354,7 @@ to silence the byte compiler. Don't use within = `eval-when-compile'." > "cc-bytecomp-defvar: Saving %s (as unbound)" ',var) > (setq cc-bytecomp-unbound-variables > (cons ',var cc-bytecomp-unbound-variables)))) > - (if (and (cc-bytecomp-is-compiling) > - (not load-in-progress)) > + (if (cc-bytecomp-is-compiling) > (progn > (defvar ,var) > (set ',var (intern (concat "cc-bytecomp-ignore-var:" > @@ -344,8 +382,7 @@ at compile time, e.g. for macros and inline = functions." > (setq cc-bytecomp-original-functions > (cons (list ',fun nil 'unbound) > cc-bytecomp-original-functions)))) > - (if (and (cc-bytecomp-is-compiling) > - (not load-in-progress)) > + (if (cc-bytecomp-is-compiling) > (progn > (fset ',fun (intern (concat "cc-bytecomp-ignore-fun:" > (symbol-name ',fun)))) > diff --git a/lisp/progmodes/cc-defs.el b/lisp/progmodes/cc-defs.el > index 1d8b8ab..b0e83f3 100644 > --- a/lisp/progmodes/cc-defs.el > +++ b/lisp/progmodes/cc-defs.el > @@ -1823,19 +1823,22 @@ system." >=20 > (defvar c-lang-const-expansion nil) >=20 > +;; Ugly hack to pull in the definition of = `cc-bytecomp-compiling-or-loading` > +;; from cc-bytecomp to make it available at loadtime. This is the = same > +;; mechanism used in cc-mode.el for `c-populate-syntax-table'. > +(defalias 'cc-bytecomp-compiling-or-loading > + (cc-eval-when-compile > + (let ((f (symbol-function 'cc-bytecomp-compiling-or-loading))) > + (if (byte-code-function-p f) f (byte-compile f))))) > + > (defsubst c-get-current-file () > ;; Return the base name of the current file. > - (let ((file (cond > - (load-in-progress > - ;; Being loaded. > - load-file-name) > - ((and (boundp 'byte-compile-dest-file) > - (stringp byte-compile-dest-file)) > - ;; Being compiled. > - byte-compile-dest-file) > - (t > - ;; Being evaluated interactively. > - (buffer-file-name))))) > + (let* ((c-or-l (cc-bytecomp-compiling-or-loading)) > + (file > + (cond > + ((eq c-or-l 'loading) load-file-name) > + ((eq c-or-l 'compiling) byte-compile-dest-file) > + ((null c-or-l) (buffer-file-name))))) > (and file > (file-name-sans-extension > (file-name-nondirectory file))))) > @@ -2073,9 +2076,7 @@ quoted." > (if (or (eq c-lang-const-expansion 'call) > (and (not c-lang-const-expansion) > (not mode)) > - load-in-progress > - (not (boundp 'byte-compile-dest-file)) > - (not (stringp byte-compile-dest-file))) > + (not (cc-bytecomp-is-compiling))) > ;; Either a straight call is requested in the context, or > ;; we're in an "uncontrolled" context and got no language, > ;; or we're not being byte compiled so the compile time > diff --git a/lisp/progmodes/cc-langs.el b/lisp/progmodes/cc-langs.el > index 68b2d62..22d78b5 100644 > --- a/lisp/progmodes/cc-langs.el > +++ b/lisp/progmodes/cc-langs.el > @@ -3252,10 +3252,7 @@ function it returns is byte compiled with all = the evaluated results > from the language constants. Use the `c-init-language-vars' macro to > accomplish that conveniently." >=20 > - (if (and (not load-in-progress) > - (boundp 'byte-compile-dest-file) > - (stringp byte-compile-dest-file)) > - > + (if (cc-bytecomp-is-compiling) > ;; No need to byte compile this lambda since the byte compiler = is > ;; smart enough to detect the `funcall' construct in the > ;; `c-init-language-vars' macro below and compile it all = straight >=20 >=20 >=20 > --=20 > Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 02 07:02:57 2014 Received: (at 19206) by debbugs.gnu.org; 2 Dec 2014 12:02:57 +0000 Received: from localhost ([127.0.0.1]:51460 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XvmAT-0004Tz-5p for submit@debbugs.gnu.org; Tue, 02 Dec 2014 07:02:57 -0500 Received: from colin.muc.de ([193.149.48.1]:32994 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XvmAP-0004Tn-KI for 19206@debbugs.gnu.org; Tue, 02 Dec 2014 07:02:54 -0500 Received: (qmail 265 invoked by uid 3782); 2 Dec 2014 12:02:52 -0000 Received: from acm.muc.de (pD951A056.dip0.t-ipconnect.de [217.81.160.86]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Dec 2014 13:02:51 +0100 Received: (qmail 4388 invoked by uid 1000); 2 Dec 2014 12:02:26 -0000 Date: Tue, 2 Dec 2014 12:02:26 +0000 To: Sebastian Wiesner Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files Message-ID: <20141202120226.GA4018@acm.acm> References: <20141128222542.60510.qmail@mail.muc.de> <20141130184221.GA12974@acm.acm> <9C8C5538-BC19-4094-832C-3F3259DE37A5@lunaryorn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9C8C5538-BC19-4094-832C-3F3259DE37A5@lunaryorn.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19206 Cc: 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hello, Sebastian. On Tue, Dec 02, 2014 at 12:03:21PM +0100, Sebastian Wiesner wrote: > > Am 30.11.2014 um 19:42 schrieb Alan Mackenzie : > > Hello, again, Sebastian. > > On Fri, Nov 28, 2014 at 10:25:42PM -0000, Alan Mackenzie wrote: > >> Hello, Sebastian. > >> In article you wrote: > >>> CC Mode tracks wrong source files when a CC Mode derived mode is > >>> installed non-interactively. [ .... ] > > OK. The problem was that CC Mode was using the flag > > `load-in-progress' to assume that a CC Mode file was being loaded, > > for example by a `require' form inside a compilation of another CC > > Mode file. This assumption breaks down when another file, such as > > cc-miscompile.el, while loading, initiates compilation of a CC Mode > > derivative. [ .... ] > > No, that wouldn't work. What I've implemented is when both loading > > and byte-compilation are active at the same time, CC Mode walks down > > the lisp stack to discover which one of them is actually active. > Well, if you say… I find this “solution” horrifying, but I am probably > just unable to appreciate the full complexity of this issue. It is horrifying. I spent quite some time over the weekend searching for a better solution, without success. The issue is quite simple: when loading and compiling are nested in some unknown order, how do you determine which of them is the "innermost" activity? But, then again, maybe I could bind the "compilation flags" to nil around each invocation of `load' inside the CC Mode compilation system. Yes, I'll give that a try. > > Please try the following patch, which seems to work in the test case you > > supplied, in the real situation, and let me know how well it works. The > > d-mode.elc produced can be successfully loaded into the Emacs that built > > it. > Do I need to build a patched Emacs to try it? You need to rebuild CC Mode, but not necessarily the Emacs core. This should do the job: emacs -Q -batch -f batch-byte-compile path/to/lisp/progmodes/cc-*.el , or you could just do a `make' from the main Emacs directory, possibly deleting cc-*.elc first, just to make sure. But feel free to wait until I've tried the alternative, better, approach above. I'll get back to you later. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 02 09:02:58 2014 Received: (at 19206) by debbugs.gnu.org; 2 Dec 2014 14:02:58 +0000 Received: from localhost ([127.0.0.1]:51522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xvo2c-0002QS-GT for submit@debbugs.gnu.org; Tue, 02 Dec 2014 09:02:58 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:14062) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xvo2a-0002QJ-Aw for 19206@debbugs.gnu.org; Tue, 02 Dec 2014 09:02:56 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscIAGA2ZVRMCqTq/2dsb2JhbABbgw6KYsdygxoEAgKBHBcBAQEBAQF8hAMBAQMBViMFCwsOJhIUGA0kLogdCdEEAQEBAQEBBAEBAQEekRQHhEsFjAuNSplNgXaEGh+CewEBAQ X-IPAS-Result: AscIAGA2ZVRMCqTq/2dsb2JhbABbgw6KYsdygxoEAgKBHBcBAQEBAQF8hAMBAQMBViMFCwsOJhIUGA0kLogdCdEEAQEBAQEBBAEBAQEekRQHhEsFjAuNSplNgXaEGh+CewEBAQ X-IronPort-AV: E=Sophos;i="5.07,380,1413259200"; d="scan'208";a="99355069" Received: from 76-10-164-234.dsl.teksavvy.com (HELO pastel.home) ([76.10.164.234]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2014 09:02:55 -0500 Received: by pastel.home (Postfix, from userid 20848) id 9262343C3; Tue, 2 Dec 2014 09:02:55 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files Message-ID: References: <20141128222542.60510.qmail@mail.muc.de> <20141130184221.GA12974@acm.acm> <9C8C5538-BC19-4094-832C-3F3259DE37A5@lunaryorn.com> <20141202120226.GA4018@acm.acm> Date: Tue, 02 Dec 2014 09:02:55 -0500 In-Reply-To: <20141202120226.GA4018@acm.acm> (Alan Mackenzie's message of "Tue, 2 Dec 2014 12:02:26 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 19206 Cc: Sebastian Wiesner , 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > It is horrifying. I spent quite some time over the weekend searching for > a better solution, without success. The issue is quite simple: when > loading and compiling are nested in some unknown order, how do you > determine which of them is the "innermost" activity? No, that is a side issue. The real issue is: why on earth do we care about the file name? We should start by saying that we should never need to answer this question. So we should reject whichever "solution" we chose to some other problem which ends up requiring such horrors. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 07 17:46:52 2014 Received: (at 19206) by debbugs.gnu.org; 7 Dec 2014 22:46:52 +0000 Received: from localhost ([127.0.0.1]:56649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxkbL-0002kv-MD for submit@debbugs.gnu.org; Sun, 07 Dec 2014 17:46:52 -0500 Received: from colin.muc.de ([193.149.48.1]:32718 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxkbI-0002kk-MM for 19206@debbugs.gnu.org; Sun, 07 Dec 2014 17:46:50 -0500 Received: (qmail 73193 invoked by uid 3782); 7 Dec 2014 22:46:47 -0000 Received: from acm.muc.de (pD951AEA2.dip0.t-ipconnect.de [217.81.174.162]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 07 Dec 2014 23:46:46 +0100 Received: (qmail 6263 invoked by uid 1000); 7 Dec 2014 22:46:19 -0000 Date: Sun, 7 Dec 2014 22:46:19 +0000 To: Sebastian Wiesner Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files Message-ID: <20141207224619.GA5449@acm.acm> References: <20141128222542.60510.qmail@mail.muc.de> <20141130184221.GA12974@acm.acm> <9C8C5538-BC19-4094-832C-3F3259DE37A5@lunaryorn.com> <20141202120226.GA4018@acm.acm> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20141202120226.GA4018@acm.acm> User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19206 Cc: 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hello, Sebastian. On Tue, Dec 02, 2014 at 12:02:26PM +0000, Alan Mackenzie wrote: > On Tue, Dec 02, 2014 at 12:03:21PM +0100, Sebastian Wiesner wrote: > > > Am 30.11.2014 um 19:42 schrieb Alan Mackenzie : > > > On Fri, Nov 28, 2014 at 10:25:42PM -0000, Alan Mackenzie wrote: > > >> In article you wrote: > > >>> CC Mode tracks wrong source files when a CC Mode derived mode is > > >>> installed non-interactively. > [ .... ] > > > OK. The problem was that CC Mode was using the flag > > > `load-in-progress' to assume that a CC Mode file was being loaded, > > > for example by a `require' form inside a compilation of another CC > > > Mode file. This assumption breaks down when another file, such as > > > cc-miscompile.el, while loading, initiates compilation of a CC Mode > > > derivative. > [ .... ] > > > No, that wouldn't work. What I've implemented is when both loading > > > and byte-compilation are active at the same time, CC Mode walks down > > > the lisp stack to discover which one of them is actually active. > > Well, if you say… I find this “solution” horrifying, but I am probably > > just unable to appreciate the full complexity of this issue. > It is horrifying. I spent quite some time over the weekend searching for > a better solution, without success. The issue is quite simple: when > loading and compiling are nested in some unknown order, how do you > determine which of them is the "innermost" activity? > But, then again, maybe I could bind the "compilation flags" to nil around > each invocation of `load' inside the CC Mode compilation system. Yes, > I'll give that a try. I gave it a try, a hard and lengthy try, but in the end it wouldn't work. So, back to the previous scheme. Please disregard, revert, or discard the previous patch I sent. Please try out the following patch in the real situation and let me know whether it works properly. The patch is to the Emacs master branch. After applying it, please first explicitly DELETE cc-*.elc (this is important), and then rebuild them, either with the make command, or something like: emacs -Q -batch -f batch-byte-compile ..../lisp/progmodes/cc-*.el With this patch I was able to generate d-mode.elc using cc-miscompile.el, then to load and run it in the same emacs version which generated it. diff --git a/lisp/progmodes/cc-bytecomp.el b/lisp/progmodes/cc-bytecomp.el index 2db5a10..926fc98 100644 --- a/lisp/progmodes/cc-bytecomp.el +++ b/lisp/progmodes/cc-bytecomp.el @@ -89,13 +89,60 @@ ;;`(message ,@args) ) +(defun cc-bytecomp-compiling-or-loading () + ;; Determine whether byte-compilation or loading is currently active, + ;; returning 'compiling, 'loading or nil. + ;; If both are active, the "innermost" activity counts. Note that + ;; compilation can trigger loading (various `require' type forms) + ;; and loading can trigger compilation (the package manager does + ;; this). We walk the lisp stack if necessary. + (cond + ((and load-in-progress + (boundp 'byte-compile-dest-file) + (stringp byte-compile-dest-file)) + (let ((n 0) elt) + (while (and + (setq elt (backtrace-frame n)) + (not (and (car elt) + (memq (cadr elt) + '(load require + byte-compile-file byte-recompile-directory + batch-byte-compile))))) + (setq n (1+ n))) + (cond + ((memq (cadr elt) '(load require)) + 'loading) + ((memq (cadr elt) '(byte-compile-file + byte-recompile-directory + batch-byte-compile)) + 'compiling) + (t ; Can't happen. + (message "cc-bytecomp-compiling-or-loading: System flags spuriously set") + nil)))) + (load-in-progress + ;; Being loaded. + 'loading) + ((and (boundp 'byte-compile-dest-file) + (stringp byte-compile-dest-file)) + ;; Being compiled. + 'compiling) + (t + ;; Being evaluated interactively. + nil))) + +(defsubst cc-bytecomp-is-compiling () + "Return non-nil if eval'ed during compilation." + (eq (cc-bytecomp-compiling-or-loading) 'compiling)) + +(defsubst cc-bytecomp-is-loading () + "Return non-nil if eval'ed during loading. +Nil will be returned if we're in a compilation triggered by the loading." + (eq (cc-bytecomp-compiling-or-loading) 'loading)) + (defun cc-bytecomp-setup-environment () ;; Eval'ed during compilation to setup variables, functions etc ;; declared with `cc-bytecomp-defvar' et al. - (if (not load-in-progress) - ;; Look at `load-in-progress' to tell whether we're called - ;; directly in the file being compiled or just from some file - ;; being loaded during compilation. + (if (not (cc-bytecomp-is-loading)) (let (p) (if cc-bytecomp-environment-set (error "Byte compilation environment already set - \ @@ -143,7 +190,7 @@ perhaps a `cc-bytecomp-restore-environment' is forgotten somewhere")) (defun cc-bytecomp-restore-environment () ;; Eval'ed during compilation to restore variables, functions etc ;; declared with `cc-bytecomp-defvar' et al. - (if (not load-in-progress) + (if (not (cc-bytecomp-is-loading)) (let (p) (setq p cc-bytecomp-unbound-variables) (while p @@ -287,8 +334,7 @@ use within `eval-when-compile'." `(eval-when-compile (if (and (fboundp 'cc-bytecomp-is-compiling) (cc-bytecomp-is-compiling)) - (if (or (not load-in-progress) - (not (featurep ,cc-part))) + (if (not (featurep ,cc-part)) (cc-bytecomp-load (symbol-name ,cc-part))) (require ,cc-part)))) @@ -301,12 +347,6 @@ afterwards. Don't use within `eval-when-compile'." (require ,feature) (eval-when-compile (cc-bytecomp-setup-environment)))) -(defun cc-bytecomp-is-compiling () - "Return non-nil if eval'ed during compilation. Don't use outside -`eval-when-compile'." - (and (boundp 'byte-compile-dest-file) - (stringp byte-compile-dest-file))) - (defmacro cc-bytecomp-defvar (var) "Binds the symbol as a variable during compilation of the file, to silence the byte compiler. Don't use within `eval-when-compile'." @@ -320,8 +360,7 @@ to silence the byte compiler. Don't use within `eval-when-compile'." "cc-bytecomp-defvar: Saving %s (as unbound)" ',var) (setq cc-bytecomp-unbound-variables (cons ',var cc-bytecomp-unbound-variables)))) - (if (and (cc-bytecomp-is-compiling) - (not load-in-progress)) + (if (cc-bytecomp-is-compiling) (progn (defvar ,var) (set ',var (intern (concat "cc-bytecomp-ignore-var:" @@ -349,8 +388,7 @@ at compile time, e.g. for macros and inline functions." (setq cc-bytecomp-original-functions (cons (list ',fun nil 'unbound) cc-bytecomp-original-functions)))) - (if (and (cc-bytecomp-is-compiling) - (not load-in-progress)) + (if (cc-bytecomp-is-compiling) (progn (fset ',fun (intern (concat "cc-bytecomp-ignore-fun:" (symbol-name ',fun)))) diff --git a/lisp/progmodes/cc-defs.el b/lisp/progmodes/cc-defs.el index 46cb2f9..f92267e 100644 --- a/lisp/progmodes/cc-defs.el +++ b/lisp/progmodes/cc-defs.el @@ -1983,19 +1983,22 @@ system." (defvar c-lang-const-expansion nil) +;; Ugly hack to pull in the definition of `cc-bytecomp-compiling-or-loading` +;; from cc-bytecomp to make it available at loadtime. This is the same +;; mechanism used in cc-mode.el for `c-populate-syntax-table'. +(defalias 'cc-bytecomp-compiling-or-loading + (cc-eval-when-compile + (let ((f (symbol-function 'cc-bytecomp-compiling-or-loading))) + (if (byte-code-function-p f) f (byte-compile f))))) + (defsubst c-get-current-file () ;; Return the base name of the current file. - (let ((file (cond - (load-in-progress - ;; Being loaded. - load-file-name) - ((and (boundp 'byte-compile-dest-file) - (stringp byte-compile-dest-file)) - ;; Being compiled. - byte-compile-dest-file) - (t - ;; Being evaluated interactively. - (buffer-file-name))))) + (let* ((c-or-l (cc-bytecomp-compiling-or-loading)) + (file + (cond + ((eq c-or-l 'loading) load-file-name) + ((eq c-or-l 'compiling) byte-compile-dest-file) + ((null c-or-l) (buffer-file-name))))) (and file (file-name-sans-extension (file-name-nondirectory file))))) @@ -2062,6 +2065,9 @@ constant. A file is identified by its base name." ;; language constant source definitions.) (c-lang-const-expansion 'call) (c-langs-are-parametric t) + (file (intern + (or (c-get-current-file) + (error "`c-lang-defconst' can only be used in a file")))) bindings pre-files) @@ -2121,9 +2127,14 @@ constant. A file is identified by its base name." ;; definitions for this symbol, to make sure the order in the ;; `source' property is correct even when files are loaded out of ;; order. - (setq pre-files (nreverse - ;; Reverse to get the right load order. - (mapcar 'car (get sym 'source)))) + (setq pre-files (mapcar 'car (get sym 'source))) + (if (memq file pre-files) + ;; This can happen when the source file (e.g. cc-langs.el) is first + ;; loaded as source, setting a 'source property entry, and then itself + ;; being compiled. + (setq pre-files (cdr (memq file pre-files)))) + ;; Reverse to get the right load order. + (setq pre-files (nreverse pre-files)) `(eval-and-compile (c-define-lang-constant ',name ,bindings @@ -2233,9 +2244,7 @@ quoted." (if (or (eq c-lang-const-expansion 'call) (and (not c-lang-const-expansion) (not mode)) - load-in-progress - (not (boundp 'byte-compile-dest-file)) - (not (stringp byte-compile-dest-file))) + (not (cc-bytecomp-is-compiling))) ;; Either a straight call is requested in the context, or ;; we're in an "uncontrolled" context and got no language, ;; or we're not being byte compiled so the compile time diff --git a/lisp/progmodes/cc-langs.el b/lisp/progmodes/cc-langs.el index 375725e..61e9239 100644 --- a/lisp/progmodes/cc-langs.el +++ b/lisp/progmodes/cc-langs.el @@ -3260,10 +3260,7 @@ function it returns is byte compiled with all the evaluated results from the language constants. Use the `c-init-language-vars' macro to accomplish that conveniently." - (if (and (not load-in-progress) - (boundp 'byte-compile-dest-file) - (stringp byte-compile-dest-file)) - + (if (cc-bytecomp-is-compiling) ;; No need to byte compile this lambda since the byte compiler is ;; smart enough to detect the `funcall' construct in the ;; `c-init-language-vars' macro below and compile it all straight -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 07 21:59:35 2014 Received: (at 19206) by debbugs.gnu.org; 8 Dec 2014 02:59:36 +0000 Received: from localhost ([127.0.0.1]:56755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxoXv-0003k5-OA for submit@debbugs.gnu.org; Sun, 07 Dec 2014 21:59:35 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:64957) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XxoXt-0003jv-UN for 19206@debbugs.gnu.org; Sun, 07 Dec 2014 21:59:34 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8PAOwQflRFxLi7/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBBFYjEAsOJhIUGA0kLogl1lkBAQEBAQEEAQEBAR6QbweESAWLAaQugXiEGSGCdwEBAQ X-IPAS-Result: Aj8PAOwQflRFxLi7/2dsb2JhbABbgweDYIVawjuCYgQCAoEkFwEBAQEBAXyEAwEBBFYjEAsOJhIUGA0kLogl1lkBAQEBAQEEAQEBAR6QbweESAWLAaQugXiEGSGCdwEBAQ X-IronPort-AV: E=Sophos;i="5.07,502,1413259200"; d="scan'208";a="99822676" Received: from 69-196-184-187.dsl.teksavvy.com (HELO pastel.home) ([69.196.184.187]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2014 21:59:33 -0500 Received: by pastel.home (Postfix, from userid 20848) id 00E9D9896; Sun, 7 Dec 2014 21:59:32 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files Message-ID: References: <20141128222542.60510.qmail@mail.muc.de> <20141130184221.GA12974@acm.acm> <9C8C5538-BC19-4094-832C-3F3259DE37A5@lunaryorn.com> <20141202120226.GA4018@acm.acm> <20141207224619.GA5449@acm.acm> Date: Sun, 07 Dec 2014 21:59:32 -0500 In-Reply-To: <20141207224619.GA5449@acm.acm> (Alan Mackenzie's message of "Sun, 7 Dec 2014 22:46:19 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 19206 Cc: Sebastian Wiesner , 19206@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > +(defun cc-bytecomp-compiling-or-loading () > + ;; Determine whether byte-compilation or loading is currently active, > + ;; returning 'compiling, 'loading or nil. > + ;; If both are active, the "innermost" activity counts. Note that > + ;; compilation can trigger loading (various `require' type forms) > + ;; and loading can trigger compilation (the package manager does > + ;; this). We walk the lisp stack if necessary. I think this deserves a longish and complete explanation of the context, i.e. *why* do we need to know the file name, in which circumstances it's used and why other solutions to those problems are worse than this hideous hack, Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 13 11:10:04 2015 Received: (at 19206-done) by debbugs.gnu.org; 13 Jan 2015 16:10:04 +0000 Received: from localhost ([127.0.0.1]:55574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YB42d-00042u-AF for submit@debbugs.gnu.org; Tue, 13 Jan 2015 11:10:03 -0500 Received: from colin.muc.de ([193.149.48.1]:19479 helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YB42a-00042N-IQ for 19206-done@debbugs.gnu.org; Tue, 13 Jan 2015 11:10:01 -0500 Received: (qmail 10933 invoked by uid 3782); 13 Jan 2015 16:09:59 -0000 Date: Tue, 13 Jan 2015 17:09:59 +0100 (CET) From: Alan Mackenzie To: 19206-done@debbugs.gnu.org Subject: Re: bug#19206: 25.0.50; CC Mode tracks wrong source files Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 19206-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) In article you wrote: > CC Mode tracks wrong source files when a CC Mode derived mode is > installed non-interactively. Bug fixed. -- Alan Mackenzie (Nuremberg, Germany). From unknown Mon Jun 23 04:09:37 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 11 Feb 2015 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator