From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: cc-mode uniform initialization support Date: Sat, 29 Aug 2015 17:54:58 -0700 Message-ID: <55E25462.2020901@dancol.org> References: <55D4CC9B.7020302@dancol.org> <20150820164905.GB3105@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H65u59HHjOWMAe7n3seod8PCTcFaeMMbR" X-Trace: ger.gmane.org 1440896133 28692 80.91.229.3 (30 Aug 2015 00:55:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2015 00:55:33 +0000 (UTC) Cc: Emacs developers To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 30 02:55:19 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 1ZVqty-0001YD-TR for ged-emacs-devel@m.gmane.org; Sun, 30 Aug 2015 02:55:19 +0200 Original-Received: from localhost ([::1]:55655 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVqtx-0001e3-AN for ged-emacs-devel@m.gmane.org; Sat, 29 Aug 2015 20:55:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVqtt-0001dA-Rx for emacs-devel@gnu.org; Sat, 29 Aug 2015 20:55:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVqtq-0005UB-Kh for emacs-devel@gnu.org; Sat, 29 Aug 2015 20:55:13 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:49536) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVqtq-0005Ga-78 for emacs-devel@gnu.org; Sat, 29 Aug 2015 20:55:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=zVLsihcgLUmV9bZJvj+ZdQarmnqLoJ+JLjXw5GrkETg=; b=MvM+Y9za4BT/8URFbwVJlTscVuYv4BGTvwyBNYvcf/rJEjPXEEzINDQhTK2SfSGayqoQLiMDlFBbCVMOacYOni1vgyiTaAeVsVWgifksdCNrCJQSl9vY53TMkK7DTq6EJotKwEJc5V/4YZiT3ffy/uIW5re15amtg4ixAvef0EOytncJGYNk0uj1CVYVaMyYeCo0D9FB/GdPCpm5sujcu0qTxjp84qE8q+Tz43o0o0ZC2KNVhXHJs/5sYitMWQ+/WMepqNpuiXaNIgt7uUC8Xl7AXEfbl4AbWeVTbpNV39mEOji7CHseGM+0BghLsbxvkb5zuK0SPd98YiJqgSROeQ==; Original-Received: from c-24-16-208-239.hsd1.wa.comcast.net ([24.16.208.239] helo=[192.168.1.175]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZVqti-00008r-IC; Sat, 29 Aug 2015 17:55:02 -0700 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <20150820164905.GB3105@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:189306 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H65u59HHjOWMAe7n3seod8PCTcFaeMMbR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 08/20/2015 09:49 AM, Alan Mackenzie wrote: > Hello, Daniel. >=20 > 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, >=20 >> 1 int foo{5}; >> 2 int bar =3D {5}; >> 3 mumble_t mumble{ >> 4 foo, >> 5 bar >> 6 }; >> 7 return {mumble, foo}; // Type inferred from function declaration >=20 > Yes. >=20 >> Working with code written in this style is a nightmare right now becau= se >> cc-mode recognizes line 4 as defun-block-intro, leading to line 5 bein= g >> indented spuriously, since cc-mode thinks it's a statement continuatio= n. >> In reality, the construct starting at line 3 is a brace list, but >> there's no syntactic clue to tell us that. >=20 > How about the fact that there's no argument list (in parens)? Is that > not sufficient to distinguish a brace list from a defun? I don't think so. In the _same_ codebase, we have code that looks like th= is: SCOPE_EXIT { statement1, statement1_cont; statement2; }; and foo("foo", something{ item1, item2}); Lots of codebases have SCOPE_EXIT-like things: the Linux kernel, for example, has a bunch of custom LIST_FOREACH-like macros, so we can't just check whether the word before the "{" is a keyword. The check for whitespace before the "{" in my patch is a really hacky heuristic for distinguishing the two cases. It works for the coding style I work with, but it's not very good in general. It's unfortunate that C++ overloaded "{" this way, since it makes it hard to locally determine what's going on syntactically. How about these rules? We'll assume we have a brace-list if: 1) we see "({" outside a macro definition, as in "foo({bar,qux})", or 2) we see a "{" preceded by "return", as in "return {1,2}" (say, in a function declared to return std::pair), or 3) we see a "{" preceded by a ",", as in "foo(foo, {bar})" (do we need to look for operators generally?), or 4) we see a "{" preceded by an identifier not in ALL CAPS. --- Do we need a separate c++11-mode so users can choose between c++-mode with the old heuristics and the new one with the hacks I've described? #1 and #4 might be controversial. >> (We can, of course, look for an "=3D", but an "=3D" is no longer requi= red >> for a brace list.) >=20 >> I don't see a way around needing to use awful heuristics to distinguis= h >> the cases. Does anyone have a better idea? Keep in mind that code like= >> this is common too: >=20 >> foo({ >> abc, >> def >> }); >=20 >> And plenty of people define macros that accept blocks: >=20 >> MY_FOREACH { >> statement1; >> statement2; >> } >=20 > 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. >=20 > 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. Thanks. > --H65u59HHjOWMAe7n3seod8PCTcFaeMMbR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV4lRiAAoJEN4WImmbpWBlEk4P/1k0cgRlcLdhdGYwcgBoKkzW VSUMm97f/yUqalUrgGNebNxCeu8KlkSW7ilu97R9t3C3uaCAu26blhdXFRcFKEkj esVInMNr2i8h0lsV/nDZGsLorNWvjPWPIgrbv6fCLewvydb2FN7bE/XTUvazULOz dyzECvv2QfzhYhZKjk9W/Fk8lRo++509FCFhzMIVrAAbO1bSPeVI4Z3YPZbRZLqi WdyhwBXtP6W+26oyUhOvHQbQg5YpnJ5z01BfaF8hPJiAZ3nFLktCq5Pg77jTNZkE TYfasJrI/1PQi8C/iH38EOU1ANqSKY05OPCAcm8Zhq0zknfUo2eeZllz8HElUxAA QF9/pIEwrYLoj30RcwjzlxWJo23iiqDm1gYT1TwJd7fhZQpoj4SPwY/3/chN8EiU fB+mhi8Qma0ZWSjOagZH7HMj0urMgeHdEYqqOWlfMsMFj6Onyio+JEeOWi8rp3mF Zc0c5GzFNRrIJdn/dCHdhtoH1IYAcRXxjdjxjsCVmzNPPlmGssl8LcZrYb00MfYV pzl7k/sDOCdmCjQ+PRFhO3V5/MrUIWrJXFq5jdNf6X9ywsS05AYedCNz9O4XnzN5 aEVUEwPogeNzAZHrvyvFb1wKh3bHJATXl6wq6zu4mj6Y99BhYAEJ0D+MV9aCu1uZ Hm7pJG8zGu4h+c4jYAOl =LJT6 -----END PGP SIGNATURE----- --H65u59HHjOWMAe7n3seod8PCTcFaeMMbR--