From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: cc-mode uniform initialization support Date: Thu, 20 Aug 2015 16:49:05 +0000 Message-ID: <20150820164905.GB3105@acm.fritz.box> References: <55D4CC9B.7020302@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1440122079 5555 80.91.229.3 (21 Aug 2015 01:54:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 21 Aug 2015 01:54:39 +0000 (UTC) Cc: Emacs developers To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 21 03:54:26 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZSbXF-0000w0-TW for ged-emacs-devel@m.gmane.org; Fri, 21 Aug 2015 03:54:26 +0200 Original-Received: from localhost ([::1]:38616 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZST18-00020j-8c for ged-emacs-devel@m.gmane.org; Thu, 20 Aug 2015 12:48:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZST0e-0001vo-3I for emacs-devel@gnu.org; Thu, 20 Aug 2015 12:48:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZST0a-0005EB-Rd for emacs-devel@gnu.org; Thu, 20 Aug 2015 12:48:12 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:27122) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZST0a-0005Dx-H8 for emacs-devel@gnu.org; Thu, 20 Aug 2015 12:48:08 -0400 Original-Received: (qmail 66995 invoked by uid 3782); 20 Aug 2015 16:48:06 -0000 Original-Received: from acm.muc.de (p548A4193.dip0.t-ipconnect.de [84.138.65.147]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 20 Aug 2015 18:48:04 +0200 Original-Received: (qmail 4279 invoked by uid 1000); 20 Aug 2015 16:49:05 -0000 Content-Disposition: inline In-Reply-To: <55D4CC9B.7020302@dancol.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189016 Archived-At: Hello, Daniel. On Wed, Aug 19, 2015 at 11:36:11AM -0700, Daniel Colascione wrote: > Recent versions of C++ support using {} to indicate an initialization > value. For example, > 1 int foo{5}; > 2 int bar = {5}; > 3 mumble_t mumble{ > 4 foo, > 5 bar > 6 }; > 7 return {mumble, foo}; // Type inferred from function declaration Yes. > Working with code written in this style is a nightmare right now because > cc-mode recognizes line 4 as defun-block-intro, leading to line 5 being > indented spuriously, since cc-mode thinks it's a statement continuation. > In reality, the construct starting at line 3 is a brace list, but > there's no syntactic clue to tell us that. How about the fact that there's no argument list (in parens)? Is that not sufficient to distinguish a brace list from a defun? > (We can, of course, look for an "=", but an "=" is no longer required > for a brace list.) > I don't see a way around needing to use awful heuristics to distinguish > the cases. Does anyone have a better idea? Keep in mind that code like > this is common too: > foo({ > abc, > def > }); > And plenty of people define macros that accept blocks: > MY_FOREACH { > statement1; > statement2; > } I've had a look at your patch, and after correcting it (so that at the indicated lines, the result of the `looking-at' is returned rather than the result of `backward-char' (which is nil)), tried it out. It does indeed appear to work on the example code you gave. However, it gives lots of errors in the test suite, including in some C++ test files (namely decls-15.cc, inexprstat-2.cc, inher-9.cc), so it needs some refinement. There are also a few niggly details where the patch isn't quite correct, but they should be easy enough to correct. Why do you distinguish between "\\w{" and "\\w {" in the `looking-at' form? > diff --git a/lisp/progmodes/cc-engine.el b/lisp/progmodes/cc-engine.el > index 06b03a2..84f3ad7 100644 > --- a/lisp/progmodes/cc-engine.el > +++ b/lisp/progmodes/cc-engine.el > @@ -8725,6 +8725,34 @@ comment at the start of cc-engine.el for more info." > (save-excursion > (goto-char containing-sexp) > (c-backward-over-enum-header)) > + ;; Detect C++11 uniform initialization. This bit is necessarily > + ;; heuristic, since there are few syntactic clues to go > + ;; on. Initializer lists can now stand in for any value at all when > + ;; the compiler can infer the type to build from the > + ;; initializer list. > + (save-excursion > + (goto-char containing-sexp) > + (and > + (eq (char-after) ?\{) > + (progn (c-backward-sws) > + (or > + ;; After a comma means universal initialization > + (eq (char-before) ?\,) > + ;; Er, we use GCC statement expressions most often in > + ;; macros, so if we see ({ outside of one, think of it > + ;; as uniform initialization. > + (and (eq (char-before) ?\() > + (save-excursion > + (not (c-beginning-of-macro)))) > + ;; foo{} versus foo {. Yuck. > + (and (not (bobp)) > + (prog1 <=================== > + (backward-char) <=================== > + (looking-at "\\(\\w\\|\\s_\\){") > + (forward-char))) > + ;; Special case for return {...} > + (looking-back "\\_ + containing-sexp)) > ;; this will pick up array/aggregate init lists, even if they are nested. > (save-excursion > (let ((class-key -- Alan Mackenzie (Nuremberg, Germany).