From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail
From: Alan Mackenzie <acm@muc.de>
Newsgroups: gmane.emacs.bugs
Subject: bug#36650: 27.0.50; CC Mode: Support C++ attributes
Date: Sun, 21 Jul 2019 11:33:05 +0000
Message-ID: <20190721113305.GA11223@ACM>
References: <20190715142718.71903.qmail@mail.muc.de>
 <87muhf9vjs.fsf@telefonica.net> <20190720180230.GB27030@ACM>
 <87d0i48hzc.fsf@telefonica.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226";
	logging-data="250379"; mail-complaints-to="usenet@blaine.gmane.org"
User-Agent: Mutt/1.10.1 (2018-07-13)
Cc: 36650@debbugs.gnu.org
To: =?UTF-8?Q?=C3=93scar?= Fuentes <ofv@wanadoo.es>
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 21 13:34:10 2019
Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>
Envelope-to: geb-bug-gnu-emacs@m.gmane.org
Original-Received: from lists.gnu.org ([209.51.188.17])
	by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.89)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>)
	id 1hpA6T-001318-TI
	for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jul 2019 13:34:10 +0200
Original-Received: from localhost ([::1]:55468 helo=lists1p.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.86_2)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>)
	id 1hpA6S-0006pw-Nd
	for geb-bug-gnu-emacs@m.gmane.org; Sun, 21 Jul 2019 07:34:08 -0400
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46403)
 by lists.gnu.org with esmtp (Exim 4.86_2)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1hpA6P-0006mL-87
 for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2019 07:34:06 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1hpA6O-0000Cf-1J
 for bug-gnu-emacs@gnu.org; Sun, 21 Jul 2019 07:34:05 -0400
Original-Received: from debbugs.gnu.org ([209.51.188.43]:49353)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
 (Exim 4.71) (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1hpA6L-000073-Q6; Sun, 21 Jul 2019 07:34:01 -0400
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
 (envelope-from <Debian-debbugs@debbugs.gnu.org>)
 id 1hpA6L-0006MP-Ln; Sun, 21 Jul 2019 07:34:01 -0400
X-Loop: help-debbugs@gnu.org
Resent-From: Alan Mackenzie <acm@muc.de>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org
Resent-Date: Sun, 21 Jul 2019 11:34:01 +0000
Resent-Message-ID: <handler.36650.B36650.156370879124389@debbugs.gnu.org>
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 36650
X-GNU-PR-Package: emacs,cc-mode
Original-Received: via spool by 36650-submit@debbugs.gnu.org id=B36650.156370879124389
 (code B ref 36650); Sun, 21 Jul 2019 11:34:01 +0000
Original-Received: (at 36650) by debbugs.gnu.org; 21 Jul 2019 11:33:11 +0000
Original-Received: from localhost ([127.0.0.1]:58174 helo=debbugs.gnu.org)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
 id 1hpA5X-0006LJ-FF
 for submit@debbugs.gnu.org; Sun, 21 Jul 2019 07:33:11 -0400
Original-Received: from colin.muc.de ([193.149.48.1]:60119 helo=mail.muc.de)
 by debbugs.gnu.org with smtp (Exim 4.84_2)
 (envelope-from <acm@muc.de>) id 1hpA5V-0006L7-1O
 for 36650@debbugs.gnu.org; Sun, 21 Jul 2019 07:33:10 -0400
Original-Received: (qmail 48460 invoked by uid 3782); 21 Jul 2019 10:40:42 -0000
Original-Received: from acm.muc.de (p2E5D592F.dip0.t-ipconnect.de [46.93.89.47]) by
 colin.muc.de (tmda-ofmipd) with ESMTP;
 Sun, 21 Jul 2019 12:40:40 +0200
Original-Received: (qmail 11253 invoked by uid 1000); 21 Jul 2019 11:33:05 -0000
Content-Disposition: inline
In-Reply-To: <87d0i48hzc.fsf@telefonica.net>
X-Delivery-Agent: TMDA/1.1.12 (Macallan)
X-Primary-Address: acm@muc.de
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 209.51.188.43
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
 the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/bug-gnu-emacs>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
 <mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org
Original-Sender: "bug-gnu-emacs"
 <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.bugs:163512
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/163512>

Hello, Óscar.

Thanks for the rapid response!

On Sun, Jul 21, 2019 at 00:21:43 +0200, Óscar Fuentes wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > The patch below (which should apply cleanly to the master branch) is
> > a first attempt at handling C++ attributes.

> Thank you Alan. Wow, it required more changes than I would expect.

These attributes can appear anywhere.  That's why.

> Seems that it mostly works. The only issue I've found so far is

> struct S {
>   S[[using : const]]()
>   : data(0)
>   {}
>   int data;
> };

> Note how ": data(0)" is not indented. If the attribute is moved before the
> name:

> struct S {
>   [[using : const]] S()
>     : data(0)
>   {}
>   int data;
> };

> or after the parameter list:

> struct S {
>   S() [[using: const]]
>     : data(0)
>   {}
>   int data;
> };


> then the indentation is correct. This only happens if the attribute is
> of the form "using:" (it is irrelevant if there is space between "using"
> and the colon).

Yes.  More precisely, it was the presence of the colon inside the
attribute which confused a low level CC Mode function
(c-crosses-statement-barrier-p).   This function scans forward for a
character which might be relevant for statement boundaries, and one of
these characters is :.  I've added handling for [[...]] into this
function, and it now seems to be working.

Would you please apply the following supplementary patch to your current
master state, try it out again, and let me know how it goes.

Thanks!



--- cc-engine.el~	2019-07-20 17:45:13.944753490 +0000
+++ cc-engine.el	2019-07-21 10:43:31.470078502 +0000
@@ -697,6 +697,21 @@
       (overlay-put (make-overlay end ol-end) 'face face))))
 
 
+(defmacro c-looking-at-c++-attribute ()
+  ;; If we're in C++ Mode, and point is at the [[ introducing an attribute,
+  ;; return the position of the end of the attribute, otherwise return nil.
+  ;; The match data are NOT preserved over this macro.
+  `(and
+    (c-major-mode-is 'c++-mode)
+    (looking-at "\\[\\[")
+    (save-excursion
+      (and
+       (c-go-list-forward)
+       (eq (char-before) ?\])
+       (eq (char-before (1- (point))) ?\])
+       (point)))))
+
+
 ;; `c-beginning-of-statement-1' and accompanying stuff.
 
 ;; KLUDGE ALERT: c-maybe-labelp is used to pass information between
@@ -1420,9 +1435,15 @@
 		      c-opt-cpp-symbol			 ; usually "#"
 		      (substring c-stmt-delim-chars 1))	 ; e.g. ";{}?:"
 	    c-stmt-delim-chars))
+	 (skip-chars
+	  (if (c-major-mode-is 'c++-mode)
+	      (concat (substring skip-chars 0 1) ; "^"
+		      "["			 ; to catch C++ attributes
+		      (substring skip-chars 1))	; e.g. "#;{}?:"
+	    skip-chars))
 	 (non-skip-list
 	  (append (substring skip-chars 1) nil)) ; e.g. (?# ?\; ?{ ?} ?? ?:)
-	 lit-range lit-start vsemi-pos)
+	 lit-range lit-start vsemi-pos attr-end)
     (save-restriction
       (widen)
       (save-excursion
@@ -1446,6 +1467,11 @@
 	     ;; In a string/comment?
 	     ((setq lit-range (c-literal-limits from))
 	      (goto-char (cdr lit-range)))
+	     ;; Skip over a C++ attribute?
+	     ((eq (char-after) ?\[)
+	      (if (setq attr-end (c-looking-at-c++-attribute))
+		  (goto-char attr-end)
+		(forward-char)))
 	     ((eq (char-after) ?:)
 	      (forward-char)
 	      (if (and (eq (char-after) ?:)
@@ -1839,21 +1865,6 @@
 ;; enclosing END, if any, else nil.
 (defvar c-sws-lit-limits nil)
 
-(defmacro c-looking-at-c++-attribute ()
-  ;; If we're in C++ Mode, and point is at the [[ introducing an attribute,
-  ;; return the position of the end of the attribute, otherwise return nil.
-  ;; The match data are NOT preserved over this macro.
-  `(and
-    (c-major-mode-is 'c++-mode)
-    (looking-at "\\[\\[")
-    (save-excursion
-      (and
-       (c-go-list-forward)
-       (eq (char-before) ?\])
-       (eq (char-before (1- (point))) ?\])
-       (point)))))
-
-;; (defmacro c-enclosing-c++-attribute ()
 (defun c-enclosing-c++-attribute ()
   ;; If we're in C++ Mode, and point is within a correctly balanced [[ ... ]]
   ;; attribute structure, return a cons of its starting and ending positions.


-- 
Alan Mackenzie (Nuremberg, Germany).