From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#57318: 29.0.50; c++-mode: Functions are shown as variables: partial template specialization Date: Tue, 30 Aug 2022 20:00:00 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40906"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57318@debbugs.gnu.org To: Naofumi Yasufuku Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 30 22:01:28 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oT7QN-000ARL-3b for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 30 Aug 2022 22:01:27 +0200 Original-Received: from localhost ([::1]:51446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oT7QM-0005kB-2E for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 30 Aug 2022 16:01:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55584) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oT7Pz-0005jt-1u for bug-gnu-emacs@gnu.org; Tue, 30 Aug 2022 16:01:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47849) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oT7Py-0001X6-NL for bug-gnu-emacs@gnu.org; Tue, 30 Aug 2022 16:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oT7Py-0006tM-3Y for bug-gnu-emacs@gnu.org; Tue, 30 Aug 2022 16:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Aug 2022 20:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57318 X-GNU-PR-Package: emacs Original-Received: via spool by 57318-submit@debbugs.gnu.org id=B57318.166188961226405 (code B ref 57318); Tue, 30 Aug 2022 20:01:02 +0000 Original-Received: (at 57318) by debbugs.gnu.org; 30 Aug 2022 20:00:12 +0000 Original-Received: from localhost ([127.0.0.1]:37598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oT7PA-0006ro-4R for submit@debbugs.gnu.org; Tue, 30 Aug 2022 16:00:12 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:44419) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oT7P6-0006qN-Le for 57318@debbugs.gnu.org; Tue, 30 Aug 2022 16:00:11 -0400 Original-Received: (qmail 20031 invoked by uid 3782); 30 Aug 2022 22:00:01 +0200 Original-Received: from acm.muc.de (p4fe159da.dip0.t-ipconnect.de [79.225.89.218]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 30 Aug 2022 22:00:00 +0200 Original-Received: (qmail 8443 invoked by uid 1000); 30 Aug 2022 20:00:00 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:241153 Archived-At: Hello, Naofumi. Thank you indeed for your bug report, and thanks even more for diagnosing the cause and writing a patch! I'm truly astounded that you managed to debug this problem, hidden as it was in the fontification parts of CC Mode, which are difficult to run with the debugger. Respect! Looking at your patch, I can see one or two problems with it. The main one is that after encountering a template opener "<", I'm a bit worried about the accuracy of checking for the matching ">". Looking further into the problem, it seems the misfontification bug was triggered by the commas in the template expressions. When there's a comma there, the (c-forward-<>-arglist ...) call (which "; Should always work") fails. This failure is caused by the dynamic binding of c-restricted-<>-arglists to t. When this dynamic binding is instead at nil (rather than t), the fontification works properly, with functions fontified as functions. The reason for this faulty binding was fixing a bug report where scrolling a buffer containing lots of templates was very slow. Binding c-restricted-<>-arglists to t "solved" that slowness. That slowness had been caused by inefficient scanning of the template structures. I've now identified and implemented an alternative optimisation, which doesn't cause problems with commas in templates. So I must apologize that I won't be using your patch, but I thoroughly appreciate the time you must have spent debugging the problem. Can I ask you, please, to apply and test my proposed patch, which I enclose below. Would you please test it on your real C++ source code, and either confirm it really works, or say what's still faulty about it. If there are any problems with applying the patch, feel free to send me personal email. diff -r 8f28cf5aae11 cc-engine.el --- a/cc-engine.el Sat Aug 27 09:10:03 2022 +0000 +++ b/cc-engine.el Tue Aug 30 19:46:56 2022 +0000 @@ -146,6 +146,11 @@ ;; Put on the brace which introduces a brace list and on the commas ;; which separate the elements within it. ;; +;; 'c-<>-c-types-set +;; This property is set on an opening angle bracket, and indicates that +;; any "," separators within the template/generic expression have been +;; marked with a 'c-type property value 'c-<>-arg-sep (see above). +;; ;; 'c-awk-NL-prop ;; Used in AWK mode to mark the various kinds of newlines. See ;; cc-awk.el. @@ -6153,7 +6158,7 @@ (forward-char)))) (backward-char) (if (let ((c-parse-and-markup-<>-arglists t) - (c-restricted-<>-arglists t)) + c-restricted-<>-arglists) (c-forward-<>-arglist nil)) ; Should always work. (when (> (point) to) (setq bound-<> (point))) @@ -8526,9 +8531,9 @@ arg-start-pos) ;; If the '<' has paren open syntax then we've marked it as an angle ;; bracket arglist before, so skip to the end. - (if (and (not c-parse-and-markup-<>-arglists) - syntax-table-prop-on-<) - + (if (and syntax-table-prop-on-< + (or (not c-parse-and-markup-<>-arglists) + (c-get-char-property (point) 'c-<>-c-types-set))) (progn (forward-char) (if (and (c-go-up-list-forward) @@ -8623,6 +8628,7 @@ (c-unmark-<->-as-paren (point))))) (c-mark-<-as-paren start) (c-mark->-as-paren (1- (point))) + (c-put-char-property start 'c-<>-c-types-set t) (c-truncate-lit-pos-cache start)) (setq res t) nil)) ; Exit the loop. diff -r 8f28cf5aae11 cc-fonts.el --- a/cc-fonts.el Sat Aug 27 09:10:03 2022 +0000 +++ b/cc-fonts.el Tue Aug 30 19:46:56 2022 +0000 @@ -937,17 +937,16 @@ (save-excursion (let ((pos (point))) (c-backward-syntactic-ws (max (- (point) 500) (point-min))) - (c-clear-char-properties - (if (and (not (bobp)) - (memq (c-get-char-property (1- (point)) 'c-type) - '(c-decl-arg-start - c-decl-end - c-decl-id-start - c-decl-type-start - c-not-decl))) - (1- (point)) - pos) - limit 'c-type))) + (when (and (not (bobp)) + (memq (c-get-char-property (1- (point)) 'c-type) + '(c-decl-arg-start + c-decl-end + c-decl-id-start + c-decl-type-start + c-not-decl))) + (setq pos (1- (point)))) + (c-clear-char-properties pos limit 'c-type) + (c-clear-char-properties pos limit 'c-<>-c-types-set))) ;; Update `c-state-cache' to the beginning of the region. This will ;; make `c-beginning-of-syntax' go faster when it's used later on, On Sun, Aug 28, 2022 at 14:33:08 +0900, Naofumi Yasufuku wrote: > Naofumi Yasufuku writes: > > Hello, > > > > In the case of C++ partial template specialization [1], functions are > > shown as variables. Please look at the attached screenshots. > > > > 1. emacs -Q > > 2. open attached C++ code "specialization.cc" > > > > attachments: > > - NG_cc-partial-specialization.png > > - OK_cc-partial-specialization.png > > - specialization.cc > > > [..snip..] > > > > After a brief investigation, the attached cc-engine.el patch seems to > > solve this issue at least, but it is not tested enough. > > > > attachments: > > - 0001-cc-mode-Fix-function-fontification-in-the-case-of-C-.patch > > > Previous patch still has a problem with sizeof() specializations. > Updated patch and screenshots are attached. > attachments: > - 0001-cc-mode-Fix-function-fontification-in-the-case-of-C-v2.patch > - NG_cc-partial-specialization-v1.png > - OK_cc-partial-specialization-v2.png > - specialization.cc > ------------------------------------------------------------- > template > class TwoSz { > public: > TwoSz() {} > private: > T1 _t1; > }; > template > class TwoSz { > public: > TwoSz() {} > private: > T _t1; > }; > ------------------------------------------------------------- > $ ./specialization > One: primary > One: specialization > Two: primary > Two: specialization > Two: specialization > Two: specialization > Two: specialization > Two: specialization > Two: specialization > Two: specialization > TwoSz: primary > TwoSz: specialization > $ > ------------------------------------------------------------- > Best regards, > Naofumi -- Alan Mackenzie (Nuremberg, Germany).