diff mbox

[C++,/,RFC] Change DERIVED_FROM_P to use tf_none?!?

Message ID 51ED7013.9040002@oracle.com
State New
Headers show

Commit Message

Paolo Carlini July 22, 2013, 5:46 p.m. UTC 
Hi all, Jason,

while looking a bit into c++/57942, I noticed (again) that in the 
definition of the predicate DERIVED_FROM_P we use tf_warning_or_error, 
not tf_none, which seems weird for a predicate, being in general able to 
produce hard errors (*). I tested the below with no regressions.

Thanks,
Paolo.

(*) Note that, depending on how it's called, the predicate can currently 
produce errors anyway, for example because it calls complete_type. This 
may or may not be all there is to c++/57942.

////////////////////

Comments

Jason Merrill July 22, 2013, 7:22 p.m. UTC | #1 
OK.

> (*) Note that, depending on how it's called, the predicate can currently produce errors anyway, for example because it calls complete_type. This may or may not be all there is to c++/57942.

It looks like lookup_base seems to deliberately avoid trying to complete 
the base, so the call to complete_type is coming from elsewhere.

Jason
Paolo Carlini July 22, 2013, 7:56 p.m. UTC | #2 
On 07/22/2013 09:22 PM, Jason Merrill wrote:
> OK.
Thanks, applied.
>> (*) Note that, depending on how it's called, the predicate can 
>> currently produce errors anyway, for example because it calls 
>> complete_type. This may or may not be all there is to c++/57942.
> It looks like lookup_base seems to deliberately avoid trying to 
> complete the base, so the call to complete_type is coming from elsewhere.
I see, indeed the comment in lookup_base:

   /* If BASE is incomplete, it can't be a base of T--and instantiating it
      might cause an error.  */

is very clear. Now, I tell you briefly what is going on: 
standard_conversion calls ptr_reasonably_similar, which, in turn calls 
comptypes. The latter, via structural_comptypes, does:

       if ((strict & COMPARE_BASE) && DERIVED_FROM_P (t1, t2))
     break;
       else if ((strict & COMPARE_DERIVED) && DERIVED_FROM_P (t2, t1))
     break;

you see, DERIVED_FROM_P, thus lookup_base, handles *both* the pair 
(base, derived) and the swapped pair (derived, base), thus for sure in 
one case the above comment / code doesn't help, because it protects vs 
the instantiation of the base argument not vs the instantiation of the t 
argument... bummer. I guess fixing the issue must be rather doable but 
at the moment I'm not clear about where to act...

Thanks!
Paolo.
Jason Merrill July 22, 2013, 9:38 p.m. UTC | #3 
I guess ptr_reasonably_similar should return false if one of the target 
types is incomplete.

Jason
diff mbox

Patch

Index: cp-tree.h
===================================================================
--- cp-tree.h	(revision 201122)
+++ cp-tree.h	(working copy)
@@ -1320,8 +1320,7 @@  enum languages { lang_c, lang_cplusplus, lang_java
 /* Nonzero iff TYPE is derived from PARENT. Ignores accessibility and
    ambiguity issues.  */
 #define DERIVED_FROM_P(PARENT, TYPE) \
-  (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_warning_or_error)\
-   != NULL_TREE)
+  (lookup_base ((TYPE), (PARENT), ba_any, NULL, tf_none) != NULL_TREE)
 
 /* Gives the visibility specification for a class type.  */
 #define CLASSTYPE_VISIBILITY(TYPE)		\