From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23674 invoked by alias); 4 Apr 2010 08:50:12 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 23627 invoked by uid 22791); 4 Apr 2010 08:50:08 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Sun, 04 Apr 2010 08:50:00 -0000 From: Dodji Seketeli To: Tom Tromey Cc: Chris Moller , Sergio Durigan Junior , Project Archer Subject: Re: Parser rewritting Message-ID: <20100404084952.GK20524@redhat.com> References: <201003301546.34866.sergiodj@redhat.com> <4BB24B69.3000300@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-URL: http://www.seketeli.org/dodji User-Agent: Mutt/1.5.20 (2009-08-17) X-SW-Source: 2010-q2/txt/msg00001.txt.bz2 On Tue, Mar 30, 2010 at 03:12:26PM -0600, Tom Tromey wrote: [...] > Chris> There are a couple of antlr C++ parsers available: > Chris> http://hg.netbeans.org/main/file/tip/cnd.modelimpl/src/org/netbeans/modules/cnd/modelimpl/parser/cppparser.g > > We can't generally reuse code like this due to copyright assignment > requirements. Would the copyright assignment requirements prevent us from trying to reuse, say, Clang? Maybe one could think about providing a C api on top of Clang and consider Clang as an external dependency? If not, then my point was to explicitely mention it and make sure we did consider the option and ruled it out based on sound reasons. [...] > My preferred route is to hand-write a recursive descent parser, > mimicing > the structure of the existing code in g++. > > I think directly sharing code is impractical due to impedance mismatch > between gdb and g++ internals. Also our goals are slightly different, > in that in gdb we only need to parse expressions, we want a single > parser for C and C++, and finally gdb must implement certain language > extensions. I understand that this minimal parser is meant to stay simple, e.g. no preprocessing support, very minimal error reporting if any at all, no semantic analysis etc, but still, if we can't re-use Clang, then would it be possible to devise this new "minimal parser" as an independant, reusable library with its own dejagnu-free testsuite? Maybe other projects might be interested in using (and extending) something like that. Dodji