public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [C++ Patch/RFC] Remove unify_success / unify_invalid unused parameter?
@ 2014-04-15 16:25 Paolo Carlini
  2014-04-16 19:59 ` Jason Merrill
  0 siblings, 1 reply; 3+ messages in thread
From: Paolo Carlini @ 2014-04-15 16:25 UTC (permalink / raw)
  To: gcc-patches; +Cc: Jason Merrill

[-- Attachment #1: Type: text/plain, Size: 324 bytes --]

Hi,

a lot of time ago I noticed that these parameters are unused: should I 
prepare a ChangeLog for the below or we have stylistic, etc, reasons for 
keeping the parameters?

Thanks,
Paolo.

PS: I also see many int return types in the various unify* which could 
as well be bool. Opinions about that?

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

[-- Attachment #2: p --]
[-- Type: text/plain, Size: 13267 bytes --]

Index: pt.c
===================================================================
--- pt.c	(revision 209420)
+++ pt.c	(working copy)
@@ -5377,7 +5377,7 @@ has_value_dependent_address (tree op)
    call.c  */
 
 static int
-unify_success (bool /*explain_p*/)
+unify_success (void)
 {
   return 0;
 }
@@ -5392,7 +5392,7 @@ unify_parameter_deduction_failure (bool explain_p,
 }
 
 static int
-unify_invalid (bool /*explain_p*/)
+unify_invalid (void)
 {
   return 1;
 }
@@ -16085,13 +16085,13 @@ check_non_deducible_conversion (tree parm, tree ar
     type = arg;
 
   if (same_type_p (parm, type))
-    return unify_success (explain_p);
+    return unify_success ();
 
   if (strict == DEDUCE_CONV)
     {
       if (can_convert_arg (type, parm, NULL_TREE, flags,
 			   explain_p ? tf_warning_or_error : tf_none))
-	return unify_success (explain_p);
+	return unify_success ();
     }
   else if (strict != DEDUCE_EXACT)
     {
@@ -16098,7 +16098,7 @@ check_non_deducible_conversion (tree parm, tree ar
       if (can_convert_arg (parm, type,
 			   TYPE_P (arg) ? NULL_TREE : arg,
 			   flags, explain_p ? tf_warning_or_error : tf_none))
-	return unify_success (explain_p);
+	return unify_success ();
     }
 
   if (strict == DEDUCE_EXACT)
@@ -16249,11 +16249,11 @@ unify_one_argument (tree tparms, tree targs, tree
   int arg_strict;
 
   if (arg == error_mark_node || parm == error_mark_node)
-    return unify_invalid (explain_p);
+    return unify_invalid ();
   if (arg == unknown_type_node)
     /* We can't deduce anything from this, but we might get all the
        template args from other function args.  */
-    return unify_success (explain_p);
+    return unify_success ();
 
   /* Implicit conversions (Clause 4) will be performed on a function
      argument to convert it to the type of the corresponding function
@@ -16269,7 +16269,7 @@ unify_one_argument (tree tparms, tree targs, tree
 	   && TYPE_P (parm) && !uses_deducible_template_parms (parm))
     /* For function parameters with only non-deducible template parameters,
        just return.  */
-    return unify_success (explain_p);
+    return unify_success ();
 
   switch (strict)
     {
@@ -16314,7 +16314,7 @@ unify_one_argument (tree tparms, tree targs, tree
 	      if (resolve_overloaded_unification
 		  (tparms, targs, parm, arg, strict,
 		   arg_strict, explain_p))
-		return unify_success (explain_p);
+		return unify_success ();
 	      return unify_overload_resolution_failure (explain_p, arg);
 	    }
 
@@ -16321,7 +16321,7 @@ unify_one_argument (tree tparms, tree targs, tree
 	  arg_expr = arg;
 	  arg = unlowered_expr_type (arg);
 	  if (arg == error_mark_node)
-	    return unify_invalid (explain_p);
+	    return unify_invalid ();
 	}
 
       arg_strict |=
@@ -16548,7 +16548,7 @@ type_unification_real (tree tparms,
     SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (targs, TREE_VEC_LENGTH (targs));
 #endif
 
-  return unify_success (explain_p);
+  return unify_success ();
 }
 
 /* Subroutine of type_unification_real.  Args are like the variables
@@ -17242,7 +17242,7 @@ unify_pack_expansion (tree tparms, tree targs, tre
 	}
     }
 
-  return unify_success (explain_p);
+  return unify_success ();
 }
 
 /* Handle unification of the domain of an array.  PARM_DOM and ARG_DOM are
@@ -17369,12 +17369,12 @@ unify (tree tparms, tree targs, tree parm, tree ar
     parm = TREE_OPERAND (parm, 0);
 
   if (arg == error_mark_node)
-    return unify_invalid (explain_p);
+    return unify_invalid ();
   if (arg == unknown_type_node
       || arg == init_list_type_node)
     /* We can't deduce anything from this, but we might get all the
        template args from other function args.  */
-    return unify_success (explain_p);
+    return unify_success ();
 
   /* If PARM uses template parameters, then we can't bail out here,
      even if ARG == PARM, since we won't record unifications for the
@@ -17381,7 +17381,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
      template parameters.  We might need them if we're trying to
      figure out which of two things is more specialized.  */
   if (arg == parm && !uses_template_parms (parm))
-    return unify_success (explain_p);
+    return unify_success ();
 
   /* Handle init lists early, so the rest of the function can assume
      we're dealing with a type. */
@@ -17401,7 +17401,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	/* We can only deduce from an initializer list argument if the
 	   parameter is std::initializer_list or an array; otherwise this
 	   is a non-deduced context. */
-	return unify_success (explain_p);
+	return unify_success ();
 
       if (TREE_CODE (parm) == ARRAY_TYPE)
 	elttype = TREE_TYPE (parm);
@@ -17413,7 +17413,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	  int elt_strict = strict;
 
 	  if (elt == error_mark_node)
-	    return unify_invalid (explain_p);
+	    return unify_invalid ();
 
 	  if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
 	    {
@@ -17436,7 +17436,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	  tree max = size_int (CONSTRUCTOR_NELTS (arg));
 	  tree idx = compute_array_index_type (NULL_TREE, max, tf_none);
 	  if (idx == error_mark_node)
-	    return unify_invalid (explain_p);
+	    return unify_invalid ();
 	  return unify_array_domain (tparms, targs, TYPE_DOMAIN (parm),
 				     idx, explain_p);
 	}
@@ -17450,7 +17450,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	  targ = listify (targ);
 	  TREE_VEC_ELT (INNERMOST_TEMPLATE_ARGS (targs), idx) = targ;
 	}
-      return unify_success (explain_p);
+      return unify_success ();
     }
 
   /* Immediately reject some pairs that won't unify because of
@@ -17485,7 +17485,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
       /* In a type which contains a nested-name-specifier, template
 	 argument values cannot be deduced for template parameters used
 	 within the nested-name-specifier.  */
-      return unify_success (explain_p);
+      return unify_success ();
 
     case TEMPLATE_TYPE_PARM:
     case TEMPLATE_TEMPLATE_PARM:
@@ -17492,7 +17492,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
     case BOUND_TEMPLATE_TEMPLATE_PARM:
       tparm = TREE_VALUE (TREE_VEC_ELT (tparms, 0));
       if (error_operand_p (tparm))
-	return unify_invalid (explain_p);
+	return unify_invalid ();
 
       if (TEMPLATE_TYPE_LEVEL (parm)
 	  != template_decl_level (tparm))
@@ -17502,7 +17502,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	  if (TREE_CODE (arg) == TREE_CODE (parm)
 	      && (is_auto (parm) ? is_auto (arg)
 		  : same_type_p (parm, arg)))
-	    return unify_success (explain_p);
+	    return unify_success ();
 	  else
 	    return unify_type_mismatch (explain_p, parm, arg);
 	}
@@ -17510,7 +17510,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
       targ = TREE_VEC_ELT (INNERMOST_TEMPLATE_ARGS (targs), idx);
       tparm = TREE_VALUE (TREE_VEC_ELT (tparms, idx));
       if (error_operand_p (tparm))
-	return unify_invalid (explain_p);
+	return unify_invalid ();
 
       /* Check for mixed types and values.  */
       if ((TREE_CODE (parm) == TEMPLATE_TYPE_PARM
@@ -17599,7 +17599,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 		  entire template argument list is a non-deduced
 		  context.  */
 	       if (PACK_EXPANSION_P (TREE_VEC_ELT (parmvec, i)))
-		 return unify_success (explain_p);
+		 return unify_success ();
 
             if (TREE_VEC_LENGTH (argvec) < len - parm_variadic_p)
               return unify_too_few_arguments (explain_p,
@@ -17632,7 +17632,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 
 	  /* Simple cases: Value already set, does match or doesn't.  */
 	  if (targ != NULL_TREE && template_args_equal (targ, arg))
-	    return unify_success (explain_p);
+	    return unify_success ();
 	  else if (targ)
 	    return unify_inconsistency (explain_p, parm, targ, arg);
 	}
@@ -17651,11 +17651,11 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	  arg = cp_build_qualified_type_real
 	    (arg, cp_type_quals (arg) & ~cp_type_quals (parm), tf_none);
 	  if (arg == error_mark_node)
-	    return unify_invalid (explain_p);
+	    return unify_invalid ();
 
 	  /* Simple cases: Value already set, does match or doesn't.  */
 	  if (targ != NULL_TREE && same_type_p (targ, arg))
-	    return unify_success (explain_p);
+	    return unify_success ();
 	  else if (targ)
 	    return unify_inconsistency (explain_p, parm, targ, arg);
 
@@ -17688,12 +17688,12 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	return unify_method_type_error (explain_p, arg);
 
       TREE_VEC_ELT (INNERMOST_TEMPLATE_ARGS (targs), idx) = arg;
-      return unify_success (explain_p);
+      return unify_success ();
 
     case TEMPLATE_PARM_INDEX:
       tparm = TREE_VALUE (TREE_VEC_ELT (tparms, 0));
       if (error_operand_p (tparm))
-	return unify_invalid (explain_p);
+	return unify_invalid ();
 
       if (TEMPLATE_PARM_LEVEL (parm)
 	  != template_decl_level (tparm))
@@ -17742,7 +17742,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
       else if (uses_template_parms (tparm))
 	/* We haven't deduced the type of this parameter yet.  Try again
 	   later.  */
-	return unify_success (explain_p);
+	return unify_success ();
       else
 	return unify_type_mismatch (explain_p, tparm, TREE_TYPE (arg));
 
@@ -17754,7 +17754,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 
       arg = strip_typedefs_expr (arg);
       TREE_VEC_ELT (INNERMOST_TEMPLATE_ARGS (targs), idx) = arg;
-      return unify_success (explain_p);
+      return unify_success ();
 
     case PTRMEM_CST:
      {
@@ -17818,7 +17818,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
       if (TYPE_DOMAIN (parm) != NULL_TREE)
 	return unify_array_domain (tparms, targs, TYPE_DOMAIN (parm),
 				   TYPE_DOMAIN (arg), explain_p);
-      return unify_success (explain_p);
+      return unify_success ();
 
     case REAL_TYPE:
     case COMPLEX_TYPE:
@@ -17838,7 +17838,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 
       /* As far as unification is concerned, this wins.	 Later checks
 	 will invalidate it if necessary.  */
-      return unify_success (explain_p);
+      return unify_success ();
 
       /* Types INTEGER_CST and MINUS_EXPR can come from array bounds.  */
       /* Type INTEGER_CST can come from ordinary constant template args.  */
@@ -17849,7 +17849,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
       if (TREE_CODE (arg) != INTEGER_CST)
 	return unify_template_argument_mismatch (explain_p, parm, arg);
       return (tree_int_cst_equal (parm, arg)
-	      ? unify_success (explain_p)
+	      ? unify_success ()
 	      : unify_template_argument_mismatch (explain_p, parm, arg));
 
     case TREE_VEC:
@@ -17877,7 +17877,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 		     P contains a pack expansion that is not the last
 		     template argument, the entire template argument list
 		     is a non-deduced context.  */
-		  return unify_success (explain_p);
+		  return unify_success ();
 	      }
 	  }
 
@@ -17903,7 +17903,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	  return unify_pack_expansion (tparms, targs, parm, arg,
 				       DEDUCE_EXACT,
 				       /*subr=*/true, explain_p);
-	return unify_success (explain_p);
+	return unify_success ();
       }
 
     case RECORD_TYPE:
@@ -17966,7 +17966,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	}
       else if (!same_type_ignoring_top_level_qualifiers_p (parm, arg))
 	return unify_type_mismatch (explain_p, parm, arg);
-      return unify_success (explain_p);
+      return unify_success ();
 
     case METHOD_TYPE:
     case FUNCTION_TYPE:
@@ -18038,7 +18038,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	return unify (tparms, targs, DECL_INITIAL (parm), arg, strict, explain_p);
       if (arg != integral_constant_value (parm))
 	return unify_template_argument_mismatch (explain_p, parm, arg);
-      return unify_success (explain_p);
+      return unify_success ();
 
     case FIELD_DECL:
     case TEMPLATE_DECL:
@@ -18062,11 +18062,11 @@ unify (tree tparms, tree targs, tree parm, tree ar
     case UNDERLYING_TYPE:
       /* Cannot deduce anything from TYPEOF_TYPE, DECLTYPE_TYPE,
 	 or UNDERLYING_TYPE nodes.  */
-      return unify_success (explain_p);
+      return unify_success ();
 
     case ERROR_MARK:
       /* Unification fails if we hit an error node.  */
-      return unify_invalid (explain_p);
+      return unify_invalid ();
 
     case INDIRECT_REF:
       if (REFERENCE_REF_P (parm))
@@ -18077,7 +18077,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
     default:
       /* An unresolved overload is a nondeduced context.  */
       if (is_overloaded_fn (parm) || type_unknown_p (parm))
-	return unify_success (explain_p);
+	return unify_success ();
       gcc_assert (EXPR_P (parm));
 
       /* We must be looking at an expression.  This can happen with
@@ -18103,7 +18103,7 @@ unify (tree tparms, tree targs, tree parm, tree ar
 	  && !template_args_equal (parm, arg))
 	return unify_expression_unequal (explain_p, parm, arg);
       else
-	return unify_success (explain_p);
+	return unify_success ();
     }
 }
 #undef RECUR_AND_CHECK_FAILURE

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [C++ Patch/RFC] Remove unify_success / unify_invalid unused parameter?
  2014-04-15 16:25 [C++ Patch/RFC] Remove unify_success / unify_invalid unused parameter? Paolo Carlini
@ 2014-04-16 19:59 ` Jason Merrill
  2014-04-16 20:34   ` Paolo Carlini
  0 siblings, 1 reply; 3+ messages in thread
From: Jason Merrill @ 2014-04-16 19:59 UTC (permalink / raw)
  To: Paolo Carlini, gcc-patches

On 04/15/2014 12:21 PM, Paolo Carlini wrote:
> a lot of time ago I noticed that these parameters are unused: should I
> prepare a ChangeLog for the below or we have stylistic, etc, reasons for
> keeping the parameters?

I'd leave them alone, we might want to print something sometime.

> PS: I also see many int return types in the various unify* which could as well be bool. Opinions about that?

Doesn't seem worth bothering to change.

Jason

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [C++ Patch/RFC] Remove unify_success / unify_invalid unused parameter?
  2014-04-16 19:59 ` Jason Merrill
@ 2014-04-16 20:34   ` Paolo Carlini
  0 siblings, 0 replies; 3+ messages in thread
From: Paolo Carlini @ 2014-04-16 20:34 UTC (permalink / raw)
  To: Jason Merrill, gcc-patches

Hi,

On 04/16/2014 09:47 PM, Jason Merrill wrote:
> On 04/15/2014 12:21 PM, Paolo Carlini wrote:
>> a lot of time ago I noticed that these parameters are unused: should I
>> prepare a ChangeLog for the below or we have stylistic, etc, reasons for
>> keeping the parameters?
>
> I'd leave them alone, we might want to print something sometime.
Makes sense.
>
>> PS: I also see many int return types in the various unify* which 
>> could as well be bool. Opinions about that?
>
> Doesn't seem worth bothering to change.
Ok. Personally, I believe that using bool instead of int, thus true and 
false instead of 1 and 0, may add clarity to the code whenever 0s and 1s 
are used as return values in the body of large functions, because one 
cannot wonder whether 2 and 3, etc, also would make sense (in fact 
elsewhere we have got functions returning int - not an enumeration type 
- with values outside 0 and 1 too, with special meanings... maybe those 
should be changed instead ;)

Paolo.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-04-16 20:15 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-15 16:25 [C++ Patch/RFC] Remove unify_success / unify_invalid unused parameter? Paolo Carlini
2014-04-16 19:59 ` Jason Merrill
2014-04-16 20:34   ` Paolo Carlini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).