[RFA] Add language-dependent post-parser

[RFA] Add language-dependent post-parser

[Paul Hilfinger]

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.
	
Index: submit.32/gdb/p-lang.c
--- submit.32/gdb/p-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/e/26_p-lang.c 1.1.1.2.2.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/p-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/e/26_p-lang.c 1.1.1.2.2.1.2.1.1.1.3.1.1.1 644)
@@ -454,6 +454,7 @@ const struct language_defn pascal_langua
   &exp_descriptor_standard,
   pascal_parse,
   pascal_error,
+  null_post_parser,
   pascal_printchar,		/* Print a character constant */
   pascal_printstr,		/* Function to print string constant */
   pascal_emit_char,		/* Print a single char */
Index: submit.32/gdb/c-lang.c
--- submit.32/gdb/c-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/g/28_c-lang.c 1.1.1.3.2.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/c-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/g/28_c-lang.c 1.1.1.3.2.1.2.1.1.1.3.1.1.1 644)
@@ -546,6 +546,7 @@ const struct language_defn c_language_de
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -604,6 +605,7 @@ const struct language_defn cplus_languag
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -639,6 +641,7 @@ const struct language_defn asm_language_
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -679,6 +682,7 @@ const struct language_defn minimal_langu
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
Index: submit.32/gdb/expression.h
--- submit.32/gdb/expression.h Thu, 25 Sep 2003 23:43:38 -0700 hilfingr (GdbPub/h/30_expression 1.1.1.2.3.1.1.1 644)
+++ submit.34/gdb/expression.h Thu, 04 Mar 2004 03:21:17 -0800 hilfingr (GdbPub/h/30_expression 1.1.1.2.3.1.1.1.2.1 644)
@@ -378,6 +378,8 @@ struct expression
 
 extern struct expression *parse_expression (char *);
 
+extern struct expression* parse_expression_in_context (char*, struct type*);
+
 extern struct expression *parse_exp_1 (char **, struct block *, int);
 
 /* The innermost context required by the stack and register variables
Index: submit.32/gdb/f-lang.c
--- submit.32/gdb/f-lang.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/h/32_f-lang.c 1.1.1.2.2.1.2.1.1.1.1.1.1.1.3.1.1.1 644)
+++ submit.34/gdb/f-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/h/32_f-lang.c 1.1.1.2.2.1.2.1.1.1.1.1.1.1.3.1.1.1.1.1 644)
@@ -465,6 +465,7 @@ const struct language_defn f_language_de
   &exp_descriptor_standard,
   f_parse,			/* parser */
   f_error,			/* parser error function */
+  null_post_parser,
   f_printchar,			/* Print character constant */
   f_printstr,			/* function to print string constant */
   f_emit_char,			/* Function to print a single character */
Index: submit.32/gdb/jv-lang.c
--- submit.32/gdb/jv-lang.c Mon, 09 Feb 2004 01:03:21 -0800 hilfingr (GdbPub/i/30_jv-lang.c 1.1.1.3.3.1.1.1.2.1.1.1.3.1.1.1 644)
+++ submit.34/gdb/jv-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/i/30_jv-lang.c 1.1.1.3.3.1.1.1.2.1.1.1.3.1.1.1.1.1 644)
@@ -1036,6 +1036,7 @@ const struct language_defn java_language
   &exp_descriptor_java,
   java_parse,
   java_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   java_emit_char,		/* Function to print a single character */
Index: submit.32/gdb/language.c
--- submit.32/gdb/language.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/34_language.c 1.1.1.3.1.1.3.1.2.1.1.1.1.1.1.1.3.1 644)
+++ submit.34/gdb/language.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/i/34_language.c 1.1.1.3.1.1.3.1.2.1.1.1.1.1.1.1.3.1.1.1 644)
@@ -1279,6 +1279,7 @@ const struct language_defn unknown_langu
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
@@ -1315,6 +1316,7 @@ const struct language_defn auto_language
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
@@ -1350,6 +1352,7 @@ const struct language_defn local_languag
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
Index: submit.32/gdb/language.h
--- submit.32/gdb/language.h Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/35_language.h 1.1.1.3.1.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/language.h Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/i/35_language.h 1.1.1.3.1.1.2.1.1.1.3.1.1.1 644)
@@ -180,6 +180,10 @@ struct language_defn
 
     void (*la_error) (char *);
 
+    /* Post-parser processing on prefixified expression, in context 
+     * expecting a particular type.  */
+    void (*la_post_parser) (struct expression **, struct type *);
+
     void (*la_printchar) (int ch, struct ui_file * stream);
 
     void (*la_printstr) (struct ui_file * stream, char *string,
Index: submit.32/gdb/m2-lang.c
--- submit.32/gdb/m2-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/38_m2-lang.c 1.1.1.2.2.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/m2-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/i/38_m2-lang.c 1.1.1.2.2.1.2.1.1.1.3.1.1.1 644)
@@ -418,6 +418,7 @@ const struct language_defn m2_language_d
   &exp_descriptor_standard,
   m2_parse,			/* parser */
   m2_error,			/* parser error function */
+  null_post_parser,
   m2_printchar,			/* Print character constant */
   m2_printstr,			/* function to print string constant */
   m2_emit_char,			/* Function to print a single character */
Index: submit.32/gdb/parse.c
--- submit.32/gdb/parse.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/j/29_parse.c 1.1.1.4.3.1.3.1.1.1.3.1 644)
+++ submit.34/gdb/parse.c Thu, 04 Mar 2004 03:21:17 -0800 hilfingr (GdbPub/j/29_parse.c 1.1.1.4.3.1.3.1.1.1.3.1.1.2 644)
@@ -104,6 +104,9 @@ static void prefixify_expression (struct
 static void prefixify_subexp (struct expression *, struct expression *, int,
 			      int);
 
+static struct expression *parse_exp_in_context (char**, struct block*, int, 
+						struct type*);
+
 void _initialize_parse (void);
 
 /* Data structure for saving values of arglist_len for function calls whose
@@ -1023,6 +1026,17 @@ prefixify_subexp (struct expression *ine
 struct expression *
 parse_exp_1 (char **stringptr, struct block *block, int comma)
 {
+  return parse_exp_in_context (stringptr, block, comma, NULL);
+}
+
+/* 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. */
+
+static struct expression*
+parse_exp_in_context (char** stringptr, struct block* block, int comma, 
+		      struct type* context_type)
+{
   struct cleanup *old_chain;
 
   lexptr = *stringptr;
@@ -1078,6 +1092,8 @@ parse_exp_1 (char **stringptr, struct bl
 
   prefixify_expression (expout);
 
+  current_language->la_post_parser (&expout, context_type);
+
   if (expressiondebug)
     dump_prefix_expression (expout, gdb_stdlog);
 
@@ -1096,6 +1112,29 @@ parse_expression (char *string)
   if (*string)
     error ("Junk after end of expression.");
   return exp;
+}
+
+
+/* As for parse_expression, 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.  */
+
+struct expression *
+parse_expression_in_context (char *string, struct type *context_type)
+{
+  struct expression* exp;
+  exp = parse_exp_in_context (&string, 0, 0, context_type);
+  if (*string != '\000')
+    error ("Junk after end of expression.");
+  return exp;
+}
+
+/* A post-parser that does nothing. */
+
+/* ARGSUSED */
+void
+null_post_parser (struct expression **exp, struct type *type)
+{
 }
 \f
 /* Stuff for maintaining a stack of types.  Currently just used by C, but
Index: submit.32/gdb/parser-defs.h
--- submit.32/gdb/parser-defs.h Thu, 25 Sep 2003 23:43:38 -0700 hilfingr (GdbPub/j/30_parser-def 1.1.1.2.4.1.1.1 644)
+++ submit.34/gdb/parser-defs.h Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/j/30_parser-def 1.1.1.2.4.1.1.1.3.1 644)
@@ -172,6 +172,8 @@ extern char *op_name_standard (enum exp_
 
 extern struct type *follow_types (struct type *);
 
+extern void null_post_parser (struct expression **exp, struct type *type);
+
 /* During parsing of a C expression, the pointer to the next character
    is in this variable.  */
 
Index: submit.32/gdb/scm-lang.c
--- submit.32/gdb/scm-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/k/14_scm-lang.c 1.1.1.3.2.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/scm-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/k/14_scm-lang.c 1.1.1.3.2.1.2.1.1.1.3.1.1.1 644)
@@ -253,6 +253,7 @@ const struct language_defn scm_language_
   &exp_descriptor_scm,
   scm_parse,
   c_error,
+  null_post_parser,
   scm_printchar,		/* Print a character constant */
   scm_printstr,			/* Function to print string constant */
   NULL,				/* Function to print a single character */
Index: submit.32/gdb/objc-lang.c
--- submit.32/gdb/objc-lang.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/C/b/24_objc-lang. 1.4.3.1.2.1.1.1.3.1.1.1 644)
+++ submit.34/gdb/objc-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/C/b/24_objc-lang. 1.4.3.1.2.1.1.1.3.1.1.1.1.1 644)
@@ -662,6 +662,7 @@ const struct language_defn objc_language
   &exp_descriptor_standard,
   objc_parse,
   objc_error,
+  null_post_parser,
   objc_printchar,		/* Print a character constant */
   objc_printstr,		/* Function to print string constant */
   objc_emit_char,

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

[Daniel Jacobowitz]

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.

Could you explain more about why you found this necessary?  It's hard
to evaluate the patch without that.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Paul Hilfinger]

> 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.

[RFA] Add language-dependent post-parser

[Paul Hilfinger]

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.
	
Index: submit.32/gdb/p-lang.c
--- submit.32/gdb/p-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/e/26_p-lang.c 1.1.1.2.2.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/p-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/e/26_p-lang.c 1.1.1.2.2.1.2.1.1.1.3.1.1.1 644)
@@ -454,6 +454,7 @@ const struct language_defn pascal_langua
   &exp_descriptor_standard,
   pascal_parse,
   pascal_error,
+  null_post_parser,
   pascal_printchar,		/* Print a character constant */
   pascal_printstr,		/* Function to print string constant */
   pascal_emit_char,		/* Print a single char */
Index: submit.32/gdb/c-lang.c
--- submit.32/gdb/c-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/g/28_c-lang.c 1.1.1.3.2.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/c-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/g/28_c-lang.c 1.1.1.3.2.1.2.1.1.1.3.1.1.1 644)
@@ -546,6 +546,7 @@ const struct language_defn c_language_de
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -604,6 +605,7 @@ const struct language_defn cplus_languag
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -639,6 +641,7 @@ const struct language_defn asm_language_
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -679,6 +682,7 @@ const struct language_defn minimal_langu
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
Index: submit.32/gdb/expression.h
--- submit.32/gdb/expression.h Thu, 25 Sep 2003 23:43:38 -0700 hilfingr (GdbPub/h/30_expression 1.1.1.2.3.1.1.1 644)
+++ submit.34/gdb/expression.h Thu, 04 Mar 2004 03:21:17 -0800 hilfingr (GdbPub/h/30_expression 1.1.1.2.3.1.1.1.2.1 644)
@@ -378,6 +378,8 @@ struct expression
 
 extern struct expression *parse_expression (char *);
 
+extern struct expression* parse_expression_in_context (char*, struct type*);
+
 extern struct expression *parse_exp_1 (char **, struct block *, int);
 
 /* The innermost context required by the stack and register variables
Index: submit.32/gdb/f-lang.c
--- submit.32/gdb/f-lang.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/h/32_f-lang.c 1.1.1.2.2.1.2.1.1.1.1.1.1.1.3.1.1.1 644)
+++ submit.34/gdb/f-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/h/32_f-lang.c 1.1.1.2.2.1.2.1.1.1.1.1.1.1.3.1.1.1.1.1 644)
@@ -465,6 +465,7 @@ const struct language_defn f_language_de
   &exp_descriptor_standard,
   f_parse,			/* parser */
   f_error,			/* parser error function */
+  null_post_parser,
   f_printchar,			/* Print character constant */
   f_printstr,			/* function to print string constant */
   f_emit_char,			/* Function to print a single character */
Index: submit.32/gdb/jv-lang.c
--- submit.32/gdb/jv-lang.c Mon, 09 Feb 2004 01:03:21 -0800 hilfingr (GdbPub/i/30_jv-lang.c 1.1.1.3.3.1.1.1.2.1.1.1.3.1.1.1 644)
+++ submit.34/gdb/jv-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/i/30_jv-lang.c 1.1.1.3.3.1.1.1.2.1.1.1.3.1.1.1.1.1 644)
@@ -1036,6 +1036,7 @@ const struct language_defn java_language
   &exp_descriptor_java,
   java_parse,
   java_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   java_emit_char,		/* Function to print a single character */
Index: submit.32/gdb/language.c
--- submit.32/gdb/language.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/34_language.c 1.1.1.3.1.1.3.1.2.1.1.1.1.1.1.1.3.1 644)
+++ submit.34/gdb/language.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/i/34_language.c 1.1.1.3.1.1.3.1.2.1.1.1.1.1.1.1.3.1.1.1 644)
@@ -1279,6 +1279,7 @@ const struct language_defn unknown_langu
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
@@ -1315,6 +1316,7 @@ const struct language_defn auto_language
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
@@ -1350,6 +1352,7 @@ const struct language_defn local_languag
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
Index: submit.32/gdb/language.h
--- submit.32/gdb/language.h Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/35_language.h 1.1.1.3.1.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/language.h Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/i/35_language.h 1.1.1.3.1.1.2.1.1.1.3.1.1.1 644)
@@ -180,6 +180,10 @@ struct language_defn
 
     void (*la_error) (char *);
 
+    /* Post-parser processing on prefixified expression, in context 
+     * expecting a particular type.  */
+    void (*la_post_parser) (struct expression **, struct type *);
+
     void (*la_printchar) (int ch, struct ui_file * stream);
 
     void (*la_printstr) (struct ui_file * stream, char *string,
Index: submit.32/gdb/m2-lang.c
--- submit.32/gdb/m2-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/38_m2-lang.c 1.1.1.2.2.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/m2-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/i/38_m2-lang.c 1.1.1.2.2.1.2.1.1.1.3.1.1.1 644)
@@ -418,6 +418,7 @@ const struct language_defn m2_language_d
   &exp_descriptor_standard,
   m2_parse,			/* parser */
   m2_error,			/* parser error function */
+  null_post_parser,
   m2_printchar,			/* Print character constant */
   m2_printstr,			/* function to print string constant */
   m2_emit_char,			/* Function to print a single character */
Index: submit.32/gdb/parse.c
--- submit.32/gdb/parse.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/j/29_parse.c 1.1.1.4.3.1.3.1.1.1.3.1 644)
+++ submit.34/gdb/parse.c Thu, 04 Mar 2004 03:21:17 -0800 hilfingr (GdbPub/j/29_parse.c 1.1.1.4.3.1.3.1.1.1.3.1.1.2 644)
@@ -104,6 +104,9 @@ static void prefixify_expression (struct
 static void prefixify_subexp (struct expression *, struct expression *, int,
 			      int);
 
+static struct expression *parse_exp_in_context (char**, struct block*, int, 
+						struct type*);
+
 void _initialize_parse (void);
 
 /* Data structure for saving values of arglist_len for function calls whose
@@ -1023,6 +1026,17 @@ prefixify_subexp (struct expression *ine
 struct expression *
 parse_exp_1 (char **stringptr, struct block *block, int comma)
 {
+  return parse_exp_in_context (stringptr, block, comma, NULL);
+}
+
+/* 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. */
+
+static struct expression*
+parse_exp_in_context (char** stringptr, struct block* block, int comma, 
+		      struct type* context_type)
+{
   struct cleanup *old_chain;
 
   lexptr = *stringptr;
@@ -1078,6 +1092,8 @@ parse_exp_1 (char **stringptr, struct bl
 
   prefixify_expression (expout);
 
+  current_language->la_post_parser (&expout, context_type);
+
   if (expressiondebug)
     dump_prefix_expression (expout, gdb_stdlog);
 
@@ -1096,6 +1112,29 @@ parse_expression (char *string)
   if (*string)
     error ("Junk after end of expression.");
   return exp;
+}
+
+
+/* As for parse_expression, 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.  */
+
+struct expression *
+parse_expression_in_context (char *string, struct type *context_type)
+{
+  struct expression* exp;
+  exp = parse_exp_in_context (&string, 0, 0, context_type);
+  if (*string != '\000')
+    error ("Junk after end of expression.");
+  return exp;
+}
+
+/* A post-parser that does nothing. */
+
+/* ARGSUSED */
+void
+null_post_parser (struct expression **exp, struct type *type)
+{
 }
 \f
 /* Stuff for maintaining a stack of types.  Currently just used by C, but
Index: submit.32/gdb/parser-defs.h
--- submit.32/gdb/parser-defs.h Thu, 25 Sep 2003 23:43:38 -0700 hilfingr (GdbPub/j/30_parser-def 1.1.1.2.4.1.1.1 644)
+++ submit.34/gdb/parser-defs.h Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/j/30_parser-def 1.1.1.2.4.1.1.1.3.1 644)
@@ -172,6 +172,8 @@ extern char *op_name_standard (enum exp_
 
 extern struct type *follow_types (struct type *);
 
+extern void null_post_parser (struct expression **exp, struct type *type);
+
 /* During parsing of a C expression, the pointer to the next character
    is in this variable.  */
 
Index: submit.32/gdb/scm-lang.c
--- submit.32/gdb/scm-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/k/14_scm-lang.c 1.1.1.3.2.1.2.1.1.1.3.1 644)
+++ submit.34/gdb/scm-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/k/14_scm-lang.c 1.1.1.3.2.1.2.1.1.1.3.1.1.1 644)
@@ -253,6 +253,7 @@ const struct language_defn scm_language_
   &exp_descriptor_scm,
   scm_parse,
   c_error,
+  null_post_parser,
   scm_printchar,		/* Print a character constant */
   scm_printstr,			/* Function to print string constant */
   NULL,				/* Function to print a single character */
Index: submit.32/gdb/objc-lang.c
--- submit.32/gdb/objc-lang.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/C/b/24_objc-lang. 1.4.3.1.2.1.1.1.3.1.1.1 644)
+++ submit.34/gdb/objc-lang.c Thu, 04 Mar 2004 02:50:17 -0800 hilfingr (GdbPub/C/b/24_objc-lang. 1.4.3.1.2.1.1.1.3.1.1.1.1.1 644)
@@ -662,6 +662,7 @@ const struct language_defn objc_language
   &exp_descriptor_standard,
   objc_parse,
   objc_error,
+  null_post_parser,
   objc_printchar,		/* Print a character constant */
   objc_printstr,		/* Function to print string constant */
   objc_emit_char,

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

[Daniel Jacobowitz]

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.

Could you explain more about why you found this necessary?  It's hard
to evaluate the patch without that.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Paul Hilfinger]

> 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.

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

[Daniel Jacobowitz]

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

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

[Paul Hilfinger]

Daniel,

Thanks for the comments.  I will revise as per your suggestions.

Paul Hilfinger

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

[Paul Hilfinger]

Here is a second version of the post-parser patch I submitted before.
The Ada module will use the post-parser to do static overloaded name
resolution at translation time.  The patch gives the current languages
a default nop post-parser.

I think I have addresses Daniel's comments.  In this revision, I have
simplified the interface to the post-parser and to
parse_expression_in_context so that instead of an expected type, they
just take a flag indicating whether the client expects a value (as
opposed to simply evaluating for side effects).  

At the moment, nothing uses this flag in the public sources.  In ACT's
code (in a change I will propose later), we have modified the 'call'
command to use this flag, and our post-parser uses the void/non-void
context distinction to disambiguate between overloaded procedures
(void-returning functions) and value-returning functions.  This sort
of limited, context-dependent disambiguation is not useful in C or
C++, but is useful in Ada.  We do not implement Ada's full
context-dependent type resolution; for the debugger, that simply turns
out to be overkill.

This better?

Paul Hilfinger
ACT, Inc.

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.
	
Index: current-public.57/gdb/p-lang.c
--- current-public.57/gdb/p-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/e/26_p-lang.c 1.1.1.2.2.1.2.1.1.1.3.1 644)
+++ submit.53(w)/gdb/p-lang.c Thu, 04 Mar 2004 02:20:35 -0800 hilfingr (GdbPub/e/26_p-lang.c 1.1.1.2.2.1.2.1.1.1.3.1.1.1 644)
@@ -454,6 +454,7 @@ const struct language_defn pascal_langua
   &exp_descriptor_standard,
   pascal_parse,
   pascal_error,
+  null_post_parser,
   pascal_printchar,		/* Print a character constant */
   pascal_printstr,		/* Function to print string constant */
   pascal_emit_char,		/* Print a single char */
Index: current-public.57/gdb/c-lang.c
--- current-public.57/gdb/c-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/g/28_c-lang.c 1.1.1.3.2.1.2.1.1.1.3.1 644)
+++ submit.53(w)/gdb/c-lang.c Thu, 04 Mar 2004 02:20:35 -0800 hilfingr (GdbPub/g/28_c-lang.c 1.1.1.3.2.1.2.1.1.1.3.1.1.1 644)
@@ -546,6 +546,7 @@ const struct language_defn c_language_de
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -604,6 +605,7 @@ const struct language_defn cplus_languag
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -639,6 +641,7 @@ const struct language_defn asm_language_
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
@@ -679,6 +682,7 @@ const struct language_defn minimal_langu
   &exp_descriptor_standard,
   c_preprocess_and_parse,
   c_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   c_emit_char,			/* Print a single char */
Index: current-public.57/gdb/expression.h
--- current-public.57/gdb/expression.h Thu, 25 Sep 2003 23:43:38 -0700 hilfingr (GdbPub/h/30_expression 1.1.1.2.3.1.1.1 644)
+++ submit.53(w)/gdb/expression.h Mon, 05 Apr 2004 03:48:52 -0700 hilfingr (GdbPub/h/30_expression 1.1.1.2.3.1.1.1.2.2 644)
@@ -378,6 +378,8 @@ struct expression
 
 extern struct expression *parse_expression (char *);
 
+extern struct expression *parse_expression_in_context (char *, int);
+
 extern struct expression *parse_exp_1 (char **, struct block *, int);
 
 /* The innermost context required by the stack and register variables
Index: current-public.57/gdb/f-lang.c
--- current-public.57/gdb/f-lang.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/h/32_f-lang.c 1.1.1.2.2.1.2.1.1.1.1.1.1.1.3.1.1.1 644)
+++ submit.53(w)/gdb/f-lang.c Thu, 04 Mar 2004 02:20:35 -0800 hilfingr (GdbPub/h/32_f-lang.c 1.1.1.2.2.1.2.1.1.1.1.1.1.1.3.1.1.1.1.1 644)
@@ -465,6 +465,7 @@ const struct language_defn f_language_de
   &exp_descriptor_standard,
   f_parse,			/* parser */
   f_error,			/* parser error function */
+  null_post_parser,
   f_printchar,			/* Print character constant */
   f_printstr,			/* function to print string constant */
   f_emit_char,			/* Function to print a single character */
Index: current-public.57/gdb/jv-lang.c
--- current-public.57/gdb/jv-lang.c Mon, 09 Feb 2004 01:03:21 -0800 hilfingr (GdbPub/i/30_jv-lang.c 1.1.1.3.3.1.1.1.2.1.1.1.3.1.1.1 644)
+++ submit.53(w)/gdb/jv-lang.c Thu, 04 Mar 2004 02:20:35 -0800 hilfingr (GdbPub/i/30_jv-lang.c 1.1.1.3.3.1.1.1.2.1.1.1.3.1.1.1.1.1 644)
@@ -1036,6 +1036,7 @@ const struct language_defn java_language
   &exp_descriptor_java,
   java_parse,
   java_error,
+  null_post_parser,
   c_printchar,			/* Print a character constant */
   c_printstr,			/* Function to print string constant */
   java_emit_char,		/* Function to print a single character */
Index: current-public.57/gdb/language.c
--- current-public.57/gdb/language.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/34_language.c 1.1.1.3.1.1.3.1.2.1.1.1.1.1.1.1.3.1 644)
+++ submit.53(w)/gdb/language.c Thu, 04 Mar 2004 02:20:35 -0800 hilfingr (GdbPub/i/34_language.c 1.1.1.3.1.1.3.1.2.1.1.1.1.1.1.1.3.1.1.1 644)
@@ -1279,6 +1279,7 @@ const struct language_defn unknown_langu
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
@@ -1315,6 +1316,7 @@ const struct language_defn auto_language
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
@@ -1350,6 +1352,7 @@ const struct language_defn local_languag
   &exp_descriptor_standard,
   unk_lang_parser,
   unk_lang_error,
+  null_post_parser,
   unk_lang_printchar,		/* Print character constant */
   unk_lang_printstr,
   unk_lang_emit_char,
Index: current-public.57/gdb/language.h
--- current-public.57/gdb/language.h Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/35_language.h 1.1.1.3.1.1.2.1.1.1.3.1 644)
+++ submit.53(w)/gdb/language.h Tue, 06 Apr 2004 00:23:54 -0700 hilfingr (GdbPub/i/35_language.h 1.1.1.3.1.1.2.1.1.1.3.1.1.2 644)
@@ -180,6 +180,14 @@ struct language_defn
 
     void (*la_error) (char *);
 
+    /* Given an expression *EXPP created by prefixifying the result of
+       la_parser, perform any remaining processing necessary to complete
+       its translation.  *EXPP may change; la_post_parser is responsible 
+       for releasing its previous contents, if necessary.  If 
+       VOID_CONTEXT_P, then no value is expected from the expression.  */
+
+    void (*la_post_parser) (struct expression ** expp, int void_context_p);
+
     void (*la_printchar) (int ch, struct ui_file * stream);
 
     void (*la_printstr) (struct ui_file * stream, char *string,
Index: current-public.57/gdb/m2-lang.c
--- current-public.57/gdb/m2-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/i/38_m2-lang.c 1.1.1.2.2.1.2.1.1.1.3.1 644)
+++ submit.53(w)/gdb/m2-lang.c Thu, 04 Mar 2004 02:20:35 -0800 hilfingr (GdbPub/i/38_m2-lang.c 1.1.1.2.2.1.2.1.1.1.3.1.1.1 644)
@@ -418,6 +418,7 @@ const struct language_defn m2_language_d
   &exp_descriptor_standard,
   m2_parse,			/* parser */
   m2_error,			/* parser error function */
+  null_post_parser,
   m2_printchar,			/* Print character constant */
   m2_printstr,			/* function to print string constant */
   m2_emit_char,			/* Function to print a single character */
Index: current-public.57/gdb/parse.c
--- current-public.57/gdb/parse.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/j/29_parse.c 1.1.1.4.3.1.3.1.1.1.3.1 644)
+++ submit.53(w)/gdb/parse.c Tue, 06 Apr 2004 00:11:39 -0700 hilfingr (GdbPub/j/29_parse.c 1.1.1.4.3.1.3.1.1.1.3.1.1.3 644)
@@ -104,6 +104,9 @@ static void prefixify_expression (struct
 static void prefixify_subexp (struct expression *, struct expression *, int,
 			      int);
 
+static struct expression *parse_exp_in_context (char **, struct block *, int, 
+						int);
+
 void _initialize_parse (void);
 
 /* Data structure for saving values of arglist_len for function calls whose
@@ -1023,6 +1026,16 @@ prefixify_subexp (struct expression *ine
 struct expression *
 parse_exp_1 (char **stringptr, struct block *block, int comma)
 {
+  return parse_exp_in_context (stringptr, block, comma, 0);
+}
+
+/* As for parse_exp_1, except that if VOID_CONTEXT_P, then
+   no value is expected from the expression.  */
+
+static struct expression *
+parse_exp_in_context (char **stringptr, struct block *block, int comma, 
+		      int void_context_p)
+{
   struct cleanup *old_chain;
 
   lexptr = *stringptr;
@@ -1078,6 +1091,8 @@ parse_exp_1 (char **stringptr, struct bl
 
   prefixify_expression (expout);
 
+  current_language->la_post_parser (&expout, void_context_p);
+
   if (expressiondebug)
     dump_prefix_expression (expout, gdb_stdlog);
 
@@ -1096,6 +1111,28 @@ parse_expression (char *string)
   if (*string)
     error ("Junk after end of expression.");
   return exp;
+}
+
+
+/* As for parse_expression, except that if VOID_CONTEXT_P, then
+   no value is expected from the expression.  */
+
+struct expression *
+parse_expression_in_context (char *string, int void_context_p)
+{
+  struct expression *exp;
+  exp = parse_exp_in_context (&string, 0, 0, void_context_p);
+  if (*string != '\000')
+    error ("Junk after end of expression.");
+  return exp;
+}
+
+/* A post-parser that does nothing */
+
+/* ARGSUSED */
+void
+null_post_parser (struct expression **exp, int void_context_p)
+{
 }
 \f
 /* Stuff for maintaining a stack of types.  Currently just used by C, but
Index: current-public.57/gdb/parser-defs.h
--- current-public.57/gdb/parser-defs.h Thu, 25 Sep 2003 23:43:38 -0700 hilfingr (GdbPub/j/30_parser-def 1.1.1.2.4.1.1.1 644)
+++ submit.53(w)/gdb/parser-defs.h Tue, 06 Apr 2004 00:12:13 -0700 hilfingr (GdbPub/j/30_parser-def 1.1.1.2.4.1.1.1.3.2 644)
@@ -172,6 +172,8 @@ extern char *op_name_standard (enum exp_
 
 extern struct type *follow_types (struct type *);
 
+extern void null_post_parser (struct expression **, int);
+
 /* During parsing of a C expression, the pointer to the next character
    is in this variable.  */
 
Index: current-public.57/gdb/scm-lang.c
--- current-public.57/gdb/scm-lang.c Sun, 25 Jan 2004 23:26:24 -0800 hilfingr (GdbPub/k/14_scm-lang.c 1.1.1.3.2.1.2.1.1.1.3.1 644)
+++ submit.53(w)/gdb/scm-lang.c Thu, 04 Mar 2004 02:20:35 -0800 hilfingr (GdbPub/k/14_scm-lang.c 1.1.1.3.2.1.2.1.1.1.3.1.1.1 644)
@@ -253,6 +253,7 @@ const struct language_defn scm_language_
   &exp_descriptor_scm,
   scm_parse,
   c_error,
+  null_post_parser,
   scm_printchar,		/* Print a character constant */
   scm_printstr,			/* Function to print string constant */
   NULL,				/* Function to print a single character */
Index: current-public.57/gdb/objc-lang.c
--- current-public.57/gdb/objc-lang.c Wed, 18 Feb 2004 01:34:45 -0800 hilfingr (GdbPub/C/b/24_objc-lang. 1.4.3.1.2.1.1.1.3.1.1.1 644)
+++ submit.53(w)/gdb/objc-lang.c Sat, 06 Mar 2004 02:52:55 -0800 hilfingr (GdbPub/C/b/24_objc-lang. 1.4.3.1.2.1.1.1.3.1.1.1.1.2 644)
@@ -662,6 +662,7 @@ const struct language_defn objc_language
   &exp_descriptor_standard,
   objc_parse,
   objc_error,
+  null_post_parser,
   objc_printchar,		/* Print a character constant */
   objc_printstr,		/* Function to print string constant */
   objc_emit_char,

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

[Daniel Jacobowitz]

On Wed, Apr 07, 2004 at 05:32:35AM -0400, Paul Hilfinger wrote:
> 
> Here is a second version of the post-parser patch I submitted before.
> The Ada module will use the post-parser to do static overloaded name
> resolution at translation time.  The patch gives the current languages
> a default nop post-parser.
> 
> I think I have addresses Daniel's comments.  In this revision, I have
> simplified the interface to the post-parser and to
> parse_expression_in_context so that instead of an expected type, they
> just take a flag indicating whether the client expects a value (as
> opposed to simply evaluating for side effects).  
> 
> At the moment, nothing uses this flag in the public sources.  In ACT's
> code (in a change I will propose later), we have modified the 'call'
> command to use this flag, and our post-parser uses the void/non-void
> context distinction to disambiguate between overloaded procedures
> (void-returning functions) and value-returning functions.  This sort
> of limited, context-dependent disambiguation is not useful in C or
> C++, but is useful in Ada.  We do not implement Ada's full
> context-dependent type resolution; for the debugger, that simply turns
> out to be overkill.
> 
> This better?

Thanks; this is OK.

> 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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Paul Hilfinger]

> Thanks; this is OK.

Thanks!  This is now committed (tested on Linux with no regressions).

P. 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.

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

[Andrew Cagney]

> A few responses:
> 
> 
>>>>> > >But I guess the point is, this is no more elegant than a second pass,
>>>>> > >and whatever you implement I should probably use for C++ anyway so it
>>>>> > >won't be an Ada-specific hook.  Does anyone else have an opinion?
> 
> 
> I guess I don't share Daniel's distaste for multiple passes.
> Generally, I've found them a useful way to cleanly modularize
> sequences of transformations on an AST.   In production compilers, the 
> downside is performance, but as Daniel also says, this really is not
> an issue with the scale of parsing we do in GDB.

Ditto.

Andrew

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

[Paul Hilfinger]

OK guys, where do we stand?  As Daniel has indicated, more elegant
options than mine appear to involve a great deal of work to existing,
stable parsing and evaluation code that works quite well right now,
thank you, and whose only offense is to be inelegant.  Ada customers
have had the functionality of being able to detect, report, and
resolve ambiguous references at parsing time (rather than at
unexpected later moments when a saved expression is evaluated) for
years, and it works pretty well (I commend the approach to the C++
folks, in fact).  How about it?

A few responses:

> > >But I guess the point is, this is no more elegant than a second pass,
> > >and whatever you implement I should probably use for C++ anyway so it
> > >won't be an Ada-specific hook.  Does anyone else have an opinion?

I guess I don't share Daniel's distaste for multiple passes.
Generally, I've found them a useful way to cleanly modularize
sequences of transformations on an AST.   In production compilers, the 
downside is performance, but as Daniel also says, this really is not
an issue with the scale of parsing we do in GDB.


> > Ok, two thoughts:
> > 
> > - how come it's in this compressed postfix form?
> > This could hardly be a memory usage problem?
> 
> Hardly - since expressions are so short-lived.  I think it's more
> likely the emphasis was on postfix than on compressed.  I wasn't around
> when any of this was being designed, of course :)  But there are two
> plausible ways to structure this sort of yacc parser - either postfix
> or tree.  Apparently someone prefered postfix.  Which is then awkward
> to work with so it becomes prefix later.
> 
> If we're going to really clean this up, I think that using a tree
> instead would be the way to go.  That's a lot of work though.

Agreed, alas.  And this change would then have to propagate through the 
evaluator code as well.  

> > - could multi-pass be better / cleaner long term?
> > Is there a language (that we care about) with overload semantics so 
> > screwed up that both the containing expression and the parameters are 
> > needed when resolving the name?
> 
> I don't think there is.

Well, there are actually two: Ada and C++ (quick, who can tell me
where C++ uses type context in name resolution?).  However, in both
cases, the GDB implementors (i.e., me in the case of Ada) chose to
ignore this part of the language for the most part, and rely on simple
bottom-up resolution.  Type resolution by context can be handy for
producing "special effects" of abstraction, but very seldom in cases
that matter much to people typing expressions into GDB.

> > One way to get an answer is to ask: how to the corresponding compilers 
> > (Ada, Java, ObjC, C++) all implement this?
> 
> The only ones I'm familiar with (GCC, EDG, etc.) all do it using a tree
> structure.  A linearized representation is just too restrictive.  And
> multi-pass is out of the question if you want good performance; while
> for GDB the performance of the expression parser is pretty marginal,
> and the expressions we parse are pretty small, for a compiler this is a
> critical bottleneck.  Every additional pass over the parse tree has a
> high cost.

At the risk of starting an irrelevant tangential discussion, I can't
resist commenting on this.  In the case of tree representations, this
cost is not as high as one might think.  Suppose we have a 10,000-line
program with 100 AST nodes per parsed line (sounds fairly generous to
me).  The overhead of a tree traversal then involves one dynamic type
dispatch (we'll say this is a C++ implementation) per node, plus a
fetch and null test for each node (for the edge leading from its
parent, counting empty trees among the 100 figure).  On today's
machines, we're talking small fractions of a second here.

Paul Hilfinger

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

[Daniel Jacobowitz]

On Wed, Mar 31, 2004 at 11:49:50AM -0500, Andrew Cagney wrote:
> 
> >>>>>> > 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.
> >>>
> >>>>> 
> >>>>> Yes, that's exactly how I'd LIKE to do it. And I would, but for one
> >>>>> miserable little fact: the expression at this point is in POSTFIX
> >>>>> form.  So, for example, I can't use evaluate_type or the evaluate_exp
> >>>>> member of exp_descriptor, both of which work on PREFIX form.
> >>
> >>>
> >>>How much work would it be to duplicate and prefixify them, then? 
> >>>prefixify_subexp has the right interface already; if you write out the
> >>>OP_FUNCALL, you could then call a function which returns a new struct
> >>>expression in prefix form containing just the call and its arguments.
> >>>It would just need to allocate enough memory (could be generous about
> >>>it and just use the size of the original expression), call
> >>>prefixify_subexp, and fiddle out->nelts.
> >>>
> >>>OK, it's not so _efficient_, but... it could be made efficient if
> >>>someone overhauls the representation at some point.
> >
> >
> >But I guess the point is, this is no more elegant than a second pass,
> >and whatever you implement I should probably use for C++ anyway so it
> >won't be an Ada-specific hook.  Does anyone else have an opinion?
> 
> Ok, two thoughts:
> 
> - how come it's in this compressed postfix form?
> This could hardly be a memory usage problem?

Hardly - since expressions are so short-lived.  I think it's more
likely the emphasis was on postfix than on compressed.  I wasn't around
when any of this was being designed, of course :)  But there are two
plausible ways to structure this sort of yacc parser - either postfix
or tree.  Apparently someone prefered postfix.  Which is then awkward
to work with so it becomes prefix later.

If we're going to really clean this up, I think that using a tree
instead would be the way to go.  That's a lot of work though.

> - could multi-pass be better / cleaner long term?
> Is there a language (that we care about) with overload semantics so 
> screwed up that both the containing expression and the parameters are 
> needed when resolving the name?

I don't think there is.

> One way to get an answer is to ask: how to the corresponding compilers 
> (Ada, Java, ObjC, C++) all implement this?

The only ones I'm familiar with (GCC, EDG, etc.) all do it using a tree
structure.  A linearized representation is just too restrictive.  And
multi-pass is out of the question if you want good performance; while
for GDB the performance of the expression parser is pretty marginal,
and the expressions we parse are pretty small, for a compiler this is a
critical bottleneck.  Every additional pass over the parse tree has a
high cost.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

>>>>> > > 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.
>>>
>>>> > 
>>>> > Yes, that's exactly how I'd LIKE to do it. And I would, but for one
>>>> > miserable little fact: the expression at this point is in POSTFIX
>>>> > form.  So, for example, I can't use evaluate_type or the evaluate_exp
>>>> > member of exp_descriptor, both of which work on PREFIX form.
>>
>>> 
>>> How much work would it be to duplicate and prefixify them, then? 
>>> prefixify_subexp has the right interface already; if you write out the
>>> OP_FUNCALL, you could then call a function which returns a new struct
>>> expression in prefix form containing just the call and its arguments.
>>> It would just need to allocate enough memory (could be generous about
>>> it and just use the size of the original expression), call
>>> prefixify_subexp, and fiddle out->nelts.
>>> 
>>> OK, it's not so _efficient_, but... it could be made efficient if
>>> someone overhauls the representation at some point.
> 
> 
> But I guess the point is, this is no more elegant than a second pass,
> and whatever you implement I should probably use for C++ anyway so it
> won't be an Ada-specific hook.  Does anyone else have an opinion?

Ok, two thoughts:

- how come it's in this compressed postfix form?
This could hardly be a memory usage problem?

- could multi-pass be better / cleaner long term?
Is there a language (that we care about) with overload semantics so 
screwed up that both the containing expression and the parameters are 
needed when resolving the name?

One way to get an answer is to ask: how to the corresponding compilers 
(Ada, Java, ObjC, C++) all implement this?

Andrew

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

[Daniel Jacobowitz]

On Wed, Mar 31, 2004 at 10:30:04AM -0500, Daniel Jacobowitz wrote:
> On Wed, Mar 31, 2004 at 03:02:45AM -0500, Paul Hilfinger wrote:
> > 
> > Daniel,
> > 
> > > 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.
> > 
> > Yes, that's exactly how I'd LIKE to do it. And I would, but for one
> > miserable little fact: the expression at this point is in POSTFIX
> > form.  So, for example, I can't use evaluate_type or the evaluate_exp
> > member of exp_descriptor, both of which work on PREFIX form.
> 
> How much work would it be to duplicate and prefixify them, then? 
> prefixify_subexp has the right interface already; if you write out the
> OP_FUNCALL, you could then call a function which returns a new struct
> expression in prefix form containing just the call and its arguments.
> It would just need to allocate enough memory (could be generous about
> it and just use the size of the original expression), call
> prefixify_subexp, and fiddle out->nelts.
> 
> OK, it's not so _efficient_, but... it could be made efficient if
> someone overhauls the representation at some point.

But I guess the point is, this is no more elegant than a second pass,
and whatever you implement I should probably use for C++ anyway so it
won't be an Ada-specific hook.  Does anyone else have an opinion?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Daniel Jacobowitz]

On Wed, Mar 31, 2004 at 03:02:45AM -0500, Paul Hilfinger wrote:
> 
> Daniel,
> 
> > 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.
> 
> Yes, that's exactly how I'd LIKE to do it. And I would, but for one
> miserable little fact: the expression at this point is in POSTFIX
> form.  So, for example, I can't use evaluate_type or the evaluate_exp
> member of exp_descriptor, both of which work on PREFIX form.

How much work would it be to duplicate and prefixify them, then? 
prefixify_subexp has the right interface already; if you write out the
OP_FUNCALL, you could then call a function which returns a new struct
expression in prefix form containing just the call and its arguments.
It would just need to allocate enough memory (could be generous about
it and just use the size of the original expression), call
prefixify_subexp, and fiddle out->nelts.

OK, it's not so _efficient_, but... it could be made efficient if
someone overhauls the representation at some point.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Paul Hilfinger]

Daniel,

> 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.

Yes, that's exactly how I'd LIKE to do it. And I would, but for one
miserable little fact: the expression at this point is in POSTFIX
form.  So, for example, I can't use evaluate_type or the evaluate_exp
member of exp_descriptor, both of which work on PREFIX form.

Paul Hilfinger

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

[Daniel Jacobowitz]

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

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

[Paul Hilfinger]

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.

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.