Jim Blandy wrote:
> Jeff Johnston <jjohnstn@redhat.com> writes:
> 
>>Here is the revised patch.
>>
>>2004-08-24  Jeff Johnston  <jjohnstn@redhat.com>
>>
>>     * dwarf2read.c (typename_concat): Change prototype to accept dwarf2_cu
>>     struct pointer as argument.  Change function to use new argument to
>>     determine language.  If language is Java, use "." as separator,
>>     otherwise, use "::".
>>     (partial_die_parent_scope): Change comment to include java.  Check
>>     language to determine if Java "." or C++ "::" separator should be used.
>>     (add_partial_symbol): Enhance tests for C++ to also test for Java.
>>     (guess_structure_name): Ditto.
>>     (read_subroutine_type): Ditto.
>>     (new_symbol): Ditto.
>>     (read_structure_type): Add Java vtable support.
>>     (read_namespace): Add Java support.
>>     * jv-exp.y (FuncStart): New pattern.
>>     (MethodInvocation): Add support for simple function calls.  Change
>>     warning message for other forms of inferior call currently not
>>     supported.
>>     * valarith.c (value_subscript): Treat an array with upper-bound
>>     of -1 as unknown size.
> 
> 
> For the dwarf2read.c part of this patch:
> 
> There are a lot of places where we're selecting the name component
> separator based on the language; I'd like compound name construction
> abstracted out into its own function.  Two possible approaches:
> 
> - typename_concat could take, in addition to the cu, a pointer to an
>   obstack.  When the obstack pointer is null, typename_concat would
>   use xmalloc as it does now; otherwise it'd use obconcat.
> 
> - If you don't like overloading the behavior of typename_concat that
>   way, you could define a new function altogether that takes a prefix,
>   a name, a cu, and an obstack, and returns the name with the prefix
>   properly attached, allocated in the obstack.
> 
> But once there's a function that does this, I think all the 'if java
> then "." else "::"' can be neatened up quite a bit.
> 
> 
> In this change:
> 
> -	    /* The semantics of C++ state that "struct foo { ... }" also
> +	    /* The semantics of C++ and Java state that "struct foo { ... }" also
> 
> 'struct foo { ... }' isn't valid Java; go ahead and say what you mean:
> 
>     /* The semantics of C++ state that "struct foo { ... }" also
>        defines a typedef for "foo".  A Java class declaration also
>        defines a typedef for the class.  Synthesize a typedef symbol
>        so that "ptype foo" works as expected.  */
> 
> 
> The new comment for typename_concat should explain what its 'cu'
> argument is used for.
> 
> The vtable pointer recognition code is kind of weird.  The use of
> 'strlen (vptr_name) - 1' looks like a bug: don't we want to include
> that last character in the comparison?  I've committed the patch
> below; could you adapt your patch to apply on top of that?
>

Ok.  How about the following revised patch which modifies typename_concat as 
suggested above plus incorporates your other comments?

2004-09-09  Jeff Johnston  <jjohnstn@redhat.com>

       * dwarf2read.c (typename_concat): Change prototype to accept dwarf2_cu
       struct pointer and obstack pointer as arguments.  Change function to
       pick separator based on language and whether prefix/suffix is NULL or
       empty.  Also support concatenating using the obstack argument.
       (partial_die_parent_scope): Change comment to include java.  Check
       language to determine if Java "." or C++ "::" separator should be used.
       (add_partial_symbol): Enhance tests for C++ to also test for Java.
       (guess_structure_name): Ditto.
      (read_subroutine_type): Ditto.
       (new_symbol): Ditto.
       (read_structure_type): Add Java vtable support.
       (read_namespace): Add Java support.
       * jv-exp.y (FuncStart): New pattern.
       (MethodInvocation): Add support for simple function calls.  Change
       warning message for other forms of inferior call currently not
       supported.
       * valarith.c (value_subscript): Treat an array with upper-bound
       of -1 as unknown size.

Ok to commit?

-- Jeff J.