Re: [RFA] Add language-dependent post-parser

[Daniel Jacobowitz <drow@false.org>]

On Tue, Mar 30, 2004 at 04:24:13AM -0500, Paul Hilfinger wrote:
> 
> Ping.  I have not yet received a reply to my last message on this
> proposed patch (submitted Thu, 4 Mar 2004 06:33:45 -0500 (EST), with
> a followup message on Fri, 5 Mar 2004 03:15:26 -0500 (EST)).   As a reminder,
> I've appended the discussion preceding the original patch and my response to
> Daniel.

Hi Paul,

I was actually hoping that someone else would comment.  I'm not fond of
this solution (it's a little too much of working around GDB rather than
fixing GDB), but that's not a very strong opinion.  Could you explain
this bit a little more?

  > determining the static types of the arguments.  While it is possible
  > to do so during parsing, it would mean partially rebuilding the
  > existing infrastructure that allows GDB to compute types and expression
  > values.  We thought it would be easier to operate on the same prefix

I don't see why you can't do it, for instance, here:
simple_exp :    simple_exp '(' arglist ')'
                        { 
                          write_exp_elt_opcode (OP_FUNCALL);
                          write_exp_elt_longcst ($3);
				/* check arguments */
                          write_exp_elt_opcode (OP_FUNCALL);
                        }
        ;

You'd have to wiggle the expression machinery to give you back the
expression node for the function name, probably by making the
write_exp_* functions return a pointer.  But that's less intrusive and
more efficient than adding a second pass.

> 
> Paul Hilfinger
> 
> Original message of 4 March (minus patch):
> 
> 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.
> 
> Paul Hilfinger
> 
> 2004-03-04  Paul N. Hilfinger  <Hilfinger@gnat.com>
> 
>         * language.h (language_defn): Add new la_post_parser field.
>         * parser-defs.h (null_post_parser): New declaration (default for
>         la_post_parser).
>         
>         * parse.c (parse_exp_1): Move code to parse_exp_in_context and
>         insert call to that function.
>         (parse_exp_in_context): New function, including code formerly in
>         parse_exp_1.  Calls language-dependent post-parser after 
>         prefixification.
>         (parse_expression_in_context): New exported function.
>         (null_post_parser): New definition.
>         * expression.h (parse_expression_in_context): Add declaration.
>         
>         * p-lang.c (pascal_language_defn): Add trivial post-parser.
>         * c-lang.c (c_language_defn): Ditto.
>         (cplus_language_defn): Ditto.
>         (asm_language_defn): Ditto.
>         (minimal_language_defn): Ditto.
>         * f-lang.c (f_language_defn): Ditto.
>         * jv-lang.c (java_language_defn): Ditto.
>         * language.c (unknown_language_defn): Ditto.
>         (auto_language_defn): Ditto.
>         (local_language_defn): Ditto.
>         * m2-lang.c (m2_language_defn): Ditto.
>         * scm-lang.c (scm_language_defn): Ditto.
>         * obj-lang.c (objc_language_defn): Ditto.
>         
> ------------------------------------------------------------
> 
> My reply to Daniel Jacobowitz of 5 March:
> 
> > Could you explain more about why you found this necessary?  It's hard
> > to evaluate the patch without that.
> 
> Daniel,
> 
> Sure.  In Ada mode, we handle overloaded functions (not just those
> that are the Ada equivalent of member functions).  More precisely, we
> resolve overloading that can be resolved bottom-up, as C++ (almost
> always) does.  The issue we encountered was the point at which GDB
> discovers it cannot resolve the overloading.
> 
> With a command such as 
> 
>      print f(3)
> 
> there is no problem: you can resolve during execution, and print an error
> message (or whatever) then.  But what about 
> 
>      cond 1 (f(3) > 12)
> 
> ?  In similar C++ examples, such as
> 
>      cond 1 (A.f(3) > 12)
> 
> you'll find that resolution problems are reported when the breakpoint is 
> hit, possibly long after the breakpoint is set.  This is safe (the program
> stops), but we felt it was somewhat annoying that one didn't notice the 
> problem earlier.  
> 
> We perform resolution in the obvious way, but that calls for
> determining the static types of the arguments.  While it is possible
> to do so during parsing, it would mean partially rebuilding the
> existing infrastructure that allows GDB to compute types and expression
> values.  We thought it would be easier to operate on the same prefix
> form that is used for evaluation.  Unfortunately, this happens only AFTER 
> the language-dependent parser returns.
> 
> Paul Hilfinger
> Ada Core Technologies, Inc.
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer