This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Add language-dependent post-parser
- From: Daniel Jacobowitz <drow at false dot org>
- To: Paul Hilfinger <hilfingr at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 2 Apr 2004 11:33:09 -0500
- Subject: Re: [RFA] Add language-dependent post-parser
- References: <20040304113345.5DADDF2EDC@nile.gnat.com>
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