[Ada] Tagged "/=" operator in GNAT tree doesn't get fully resolved with -gnatc

[Arnaud Charlet]

When an inequality operator is used for a tagged type, the tree node for
the inequality prior to expansion (such as with -gnatc) reflects "/="
operator in Standard rather than being resolved to be a logical negation
of the tagged type's equality function. This is a problem for ASIS in
Corresponding_Equality_Operator. We now ensure that the rewriting of
a tagged inequality happens during analysis rather than being deferred
to expansion.

No simple test available.

Tested on x86_64-pc-linux-gnu, committed on trunk

2012-10-01  Gary Dismukes  <dismukes@adacore.com>

	* sem_ch4.adb (Find_Equality_Types.Try_One_Interp): Exclude the
	predefined interpretation from consideration if it's for a "/="
	operator of a tagged type. This will allow Analyze_Equality_Op to
	rewrite the "/=" as a logical negation of a call to the appropriate
	dispatching equality function. This needs to be done during
	analysis rather than expansion for the benefit of ASIS, which
	otherwise gets the unresolved N_Op_Ne operator from Standard.

-------------- next part --------------
Index: sem_ch4.adb
===================================================================
--- sem_ch4.adb	(revision 191890)
+++ sem_ch4.adb	(working copy)
@@ -5612,8 +5612,24 @@
             return;
          end if;
 
+         --  If the right operand has a type compatible with T1, check for an
+         --  acceptable interpretation, unless T1 is limited (no predefined
+         --  equality available), or this is use of a "/=" for a tagged type.
+         --  In the latter case, possible interpretations of equality need to
+         --  be considered, we don't want the default inequality declared in
+         --  Standard to be chosen, and the "/=" will be rewritten as a
+         --  negation of "=" (see the end of Analyze_Equality_Op). This ensures
+         --  that that rewriting happens during analysis rather than being
+         --  delayed until expansion (this is needed for ASIS, which only sees
+         --  the unexpanded tree). Note that if the node is N_Op_Ne, but Op_Id
+         --  is Name_Op_Eq then we still proceed with the interpretation,
+         --  because that indicates the potential rewriting case where the
+         --  interpretation to consider is actually "=" and the node may be
+         --  about to be rewritten by Analyze_Equality_Op.
+
          if T1 /= Standard_Void_Type
            and then Has_Compatible_Type (R, T1)
+
            and then
              ((not Is_Limited_Type (T1)
                 and then not Is_Limited_Composite (T1))
@@ -5622,6 +5638,11 @@
                  (Is_Array_Type (T1)
                    and then not Is_Limited_Type (Component_Type (T1))
                    and then Available_Full_View_Of_Component (T1)))
+
+           and then
+             (Nkind (N) /= N_Op_Ne
+               or else not Is_Tagged_Type (T1)
+               or else Chars (Op_Id) = Name_Op_Eq)
          then
             if Found
               and then Base_Type (T1) /= Base_Type (T_F)