(Ada) Handle same component names when searching in tagged types

(Ada) Handle same component names when searching in tagged types

Consider the following code:

   type Top_T is tagged record
      N : Integer := 1;
      U : Integer := 974;
      A : Integer := 48;
   end record;

   type Middle_T is new Top.Top_T with record
      N : Character := 'a';
      C : Integer := 3;
   end record;

  type Bottom_T is new Middle.Middle_T with record
     N : Float := 4.0;
     C : Character := '5';
     X : Integer := 6;
     A : Character := 'J';
  end record;

Tagged records in Ada provide object-oriented features, and what
is interesting in the code above is that a child tagged record
introduce additional components (fields) which sometimes have
the same name as one of the components in the parent. For instance,
Bottom_T introduces a component named "C", while at the same time
inheriting from Middle_T which also has a component named "C";
so, in essence, type Bottom_T has two components with the same name!

And before people start wondering why the language can possibly
be allowing that, this can only happen if the parent type has
a private definition. In our case, this was brought to our attention
when the parent was a generic paramenter.

With that in mind...  Let's say we now have a variable declared
and initialized as follow:

  TC : Top_A := new Bottom_T;

And then we use this variable to call this function

  procedure Assign (Obj: in out Top_T; TV : Integer);

  as follow:

  Assign (Top_T (B), 12);

Now, we're in the debugger, and we're inside that procedure
(Top.Assign in our gdb testcase), and we want to print
the value of obj.c:

Usually, the tagged record or one of the parent type owns the
component to print and there's no issue but in this particular
case, what does it mean to ask for Obj.C ? Since the actual
type for object is type Bottom_T, it could mean two things: type
component C from the Middle_T view, but also component C from
Bottom_T. So in that "undefined" case, when the component is
not found in the non-resolved type (which includes all the
components of the parent type), then resolve it and see if we
get better luck once expanded.

In the case of homonyms in the derived tagged type, we don't
guaranty anything, and pick the one that's easiest for us
to program.

This patch fixes the behavior like described above.

gdb/ChangeLog:

        * ada-lang.c (ada_value_primitive_field): Handle field search
        in case of homonyms.
        (find_struct_field): Ditto.
        (ada_search_struct_field): Ditto.
        (ada_value_struct_elt): Ditto.
        (ada_lookup_struct_elt_type): Ditto.

gdb/testsuite/ChangeLog:

        * gdb.ada/same_component_name: New testcase.

Tested on x86_64-linux.