From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5149 invoked by alias); 2 Apr 2004 16:33:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5137 invoked from network); 2 Apr 2004 16:33:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 2 Apr 2004 16:33:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B9RbR-0003gw-Pe; Fri, 02 Apr 2004 11:33:09 -0500 Date: Fri, 02 Apr 2004 16:33:00 -0000 From: Daniel Jacobowitz To: Paul Hilfinger Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Add language-dependent post-parser Message-ID: <20040402163309.GA12915@nevyn.them.org> Mail-Followup-To: Paul Hilfinger , gdb-patches@sources.redhat.com References: <20040304113345.5DADDF2EDC@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040304113345.5DADDF2EDC@nile.gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-04/txt/msg00058.txt.bz2 On Thu, Mar 04, 2004 at 06:33:45AM -0500, Paul Hilfinger wrote: > > For Ada, we found it convenient to do a name-resolution pass after parsing and > before evaluation of expressions. The most convenient form on which to > perform this resolution is the prefix form (that way, we can use the usual > type-computing machinery already included in expression evaluation). > Unfortunately, prefixification occurs after and separate from parsing. > The obvious thing to do was to add a function to the language vector for > post-parsing. For most languages, it does nothing. The patch below > does most of the work in inserting this hook, including the introduction > of a parse-in-type-context function that provides a type context for > the post-parser. In its current form, this patch is a NOP that merely > provides the hooks. Well, I think the issue of the post-parser pass is settled. Now to look at the patch. > +extern struct expression* parse_expression_in_context (char*, struct type*); Formatting - spaces before the '*'. This recurs throughout the patch. > + /* Post-parser processing on prefixified expression, in context > + * expecting a particular type. */ > + void (*la_post_parser) (struct expression **, struct type *); > + This comment doesn't make much sense to me. > +/* As for parse_exp_1, except give preference to CONTEXT_TYPE as the > + type of the result value, if CONTEXT_TYPE is non-null, in languages > + where context can determine resolution. */ Formatting (two spaces after period), but again I'm more concerned that I don't understand what this comment is trying to say. Also, it incorrectly suggests that parse_exp_in_context cares about the context type, which it doesn't - there's no way of knowing what the la_post_parser pass will do with it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer