From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp Date: Mon, 12 Jan 2015 21:01:53 +0100 Message-ID: References: <83bnxuzyl4.fsf@gnu.org> <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> <87y4p7rgf5.fsf@engster.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1421092932 2184 80.91.229.3 (12 Jan 2015 20:02:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Jan 2015 20:02:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Engster Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 12 21:02:06 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 1YAlBd-0005e0-QM for ged-emacs-devel@m.gmane.org; Mon, 12 Jan 2015 21:02:06 +0100 Original-Received: from localhost ([::1]:36144 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAlBc-0000zY-QR for ged-emacs-devel@m.gmane.org; Mon, 12 Jan 2015 15:02:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAlBY-0000zP-RU for emacs-devel@gnu.org; Mon, 12 Jan 2015 15:02:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YAlBV-0004Ms-J0 for emacs-devel@gnu.org; Mon, 12 Jan 2015 15:02:00 -0500 Original-Received: from mail-we0-x22e.google.com ([2a00:1450:400c:c03::22e]:43301) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YAlBV-0004Mc-83 for emacs-devel@gnu.org; Mon, 12 Jan 2015 15:01:57 -0500 Original-Received: by mail-we0-f174.google.com with SMTP id k48so21097281wev.5 for ; Mon, 12 Jan 2015 12:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=W+kzZNL5o0eZCQDNQ+nPV2LMxhrSxuJ5IAh5KubsKjU=; b=DlYuYxi6Z3OK8Eh89OyOKXPdMD9VjBEvRSZF0DpM6o6tnvzhHKo+4qtPfbbaMr94Xe U+hkypiww+9tSAH7rl+zonpVta/Zb9fk2fJSYnk4+a7XE3+m4vZzmF+h9/shexu2gALI U2nzbtk4yquPyRAgmMX3Yx/bdGwDGdkoq0izKSfiPbYxO7q9CV6Hk/RoMJnmuDZgxujp taubORgdeFu4t3ZEoTz2VMS1nuhfNWgp5CMbT200YDlNsnG9Te7x22LkDrR7Ic/J4XUN zbqzDscnk823meMQMxDjmfqgWoKxesubdFiGPKFzowqdXzCQpnLI77ITDC/kjHNWiJr6 AUlQ== X-Received: by 10.194.80.193 with SMTP id t1mr61822370wjx.8.1421092915812; Mon, 12 Jan 2015 12:01:55 -0800 (PST) Original-Received: from ix ([212.46.173.40]) by mx.google.com with ESMTPSA id fi10sm4465879wib.13.2015.01.12.12.01.54 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 12 Jan 2015 12:01:54 -0800 (PST) Original-Received: from helmut by ix with local (Exim 4.80) (envelope-from ) id 1YAlBR-0001dv-O0; Mon, 12 Jan 2015 21:01:54 +0100 In-Reply-To: <87y4p7rgf5.fsf@engster.org> (David Engster's message of "Mon, 12 Jan 2015 19:40:30 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::22e 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:181192 Archived-At: On Mon, Jan 12 2015, David Engster wrote: > 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? Thanks for the detailed answer! > 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. I'm a bit confused because at one side you seem to say that certain things are not possible with plugins but at the other side you seem to think that plugins can dump enough information to make these things possible. > 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. I can imagine that templates are complicated. I tried to implement a find-definition command as a GCC plugin. My first approach was to search the smallest subtree that contains a particular source location. That didn't work out because GCC doesn't record "source ranges" so it's difficult to know if a tree covers a particular location. Another problem is that identifiers are resolved early eg. "x + y" produces a PLUS_EXPR (with the source location pointing to the + sign) but the arguments are pointers to the VAR_DECLs of x and y and the source location of those VAR_DECLs is typically a few lines earlier. In a second attempt I made Emacs insert a custom #pragma at the place where we want to search for a definition; similar to the gccsense approach. Plugins can register pragmas and that way have access to the lexer. That kinda works but the problem is that pragmas are only allowed in certain places (eg. at the end of a statement) and Emacs has to guess where those places are. > 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. Is the idea is to let GCC output some "global" information like type declarations to enable better "local" parsing of function bodies in Emacs? Or do you want to do pretty much all parsing in GCC? > 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. Completion seems to be difficult problem. find-definition looks simpler and perhaps better as a first step. > So in a nutshell, for people familiar with clang: my approach is more > like using libtooling/libast than libclang. I know libclang only a bit and libtooling/libast not at all. What I failed to implement is like libclang's clang_getCursor. [...] > 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. In general I think the heavy lifting should be done in GCC+plugin and Emacs should only do the "easy" stuff like displaying the result. But for performance and other reasons it might be necessary to do at least some parsing in Emacs too. Helmut