From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Engster Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Mon, 12 Jan 2015 19:40:30 +0100 Message-ID: <87y4p7rgf5.fsf@engster.org> References: <83bnxuzyl4.fsf@gnu.org> <20140301215057.GA19461@thyrsus.com> <87fvn1y0vx.fsf@fencepost.gnu.org> <87fvn0senq.fsf@uwakimon.sk.tsukuba.ac.jp> <8761nusb90.fsf@uwakimon.sk.tsukuba.ac.jp> <87vbkovhh7.fsf@engster.org> <87387rvobr.fsf@engster.org> <87y4p9885b.fsf@fx.delysid.org> <87387hrs71.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421088061 18365 80.91.229.3 (12 Jan 2015 18:41:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Jan 2015 18:41:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 12 19:40:52 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 1YAjv0-0007m6-VS for ged-emacs-devel@m.gmane.org; Mon, 12 Jan 2015 19:40:51 +0100 Original-Received: from localhost ([::1]:35905 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAjv0-0006GA-3d for ged-emacs-devel@m.gmane.org; Mon, 12 Jan 2015 13:40:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAjuv-0006G3-Im for emacs-devel@gnu.org; Mon, 12 Jan 2015 13:40:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAjus-00035v-Aj for emacs-devel@gnu.org; Mon, 12 Jan 2015 13:40:45 -0500 Original-Received: from randomsample.de ([5.45.97.173]:42827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAjur-000341-Pl for emacs-devel@gnu.org; Mon, 12 Jan 2015 13:40:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=randomsample.de; s=a; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=V9E0azY4uzOaM5QWPi6n4cYLojQrppKyxskaldq/qr4=; b=R9oAlfP8WIuJdNO6I23DQ/og+yJDjBgO2I30/Jj5HO/p5aqlsAgZ9Bk6FxoSGKTX8FGPoF30sdX1yJQ8BqpBByOi2/Xk8AXMF4PM0XV+QtFXIzDf/1G+D0MyztfMdt6E; Original-Received: from ip4d154cb9.dynamic.kabel-deutschland.de ([77.21.76.185] helo=spaten) by randomsample.de with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YAjul-00005o-84; Mon, 12 Jan 2015 19:40:35 +0100 In-Reply-To: (Helmut Eller's message of "Mon, 12 Jan 2015 19:00:21 +0100") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.91 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 5.45.97.173 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:181189 Archived-At: Helmut Eller writes: > On Sun, Jan 11 2015, David Engster wrote: > >> AFAIK, this is not possible with a mere GCC >> plugin. > > So what was your plan (or code, if any) before you abandoned this > project? The first step would have been to replace our existing C++ parser with the AST that is produced by GCC. The plugin would output the same LISP structures that Semantic uses. My work so far was mainly to investigate how C++ types are actually stored in the AST. Especially the template stuff is pretty weird, and documentation is sparse. Fortunately, the headers are pretty well commented, but it still involves a *lot* of trial and error. The actual "semantic" part of parsing C++ would still be handled by Emacs' Semantic package. For instance, it would calculate completions. So obviously, those completions wouldn't match those from libclang w.r.t. to accuracy, but they would be *much* better than they are now, especially because the preprocessor is already handled, which is currently one of Semantic's main problems. Also, type inference would already be done by GCC, so you would see the resulting type from 'auto' and such. One main problem would be how to parse the file you're currently working on, since it usually unparseable. I don't have a good answer for that. We would have our internal parser as fallback, but I would think that we could also try to internally make the file parseable before sending it to GCC. It would probably be very messy and involve a lot of closing braces. So in a nutshell, for people familiar with clang: my approach is more like using libtooling/libast than libclang. All this would have already occupied my spare time for many, many months, so after this, my plans are very vague. People would probably want "perfect" completions similar to libclang and not the one by Semantic. These would have to be provided by GCC itself. Maybe the 'gccsense' patch could serve as a starting point here, but this would need support from an experienced GCC hacker. My plan was also to make this plugin usable for other tools. That means, it should not only output LISP structures, but alternatively also JSON and possibly XML. For instance, an external tool could build a symbol database for providing references. This could also serve as a starting point for doing refactoring. For more complicated tasks, the plugin could provide an AST matcher which you can query with certain expressions. My plan was also to investigate how much work it would be to serve the AST for other frontends, like Fortran, Go, Java and Ada. I think this would be the prime advantage over libclang, which is restricted to the C-family. I haven't looked into it, but I would think that it shouldn't be too difficult. -David