On 05/26/2011 03:04 PM, Nathan Froyd wrote:
Thanks, this is looking pretty close. A few more issues, mostly to do
with wording of the diagnostics:
@@ -14084,7 +14350,7 @@ fn_type_unification (tree fn,
sarg = tree_cons (NULL_TREE, TREE_TYPE (substed), sarg);
for (i = 0;
On 05/27/2011 04:22 PM, Nathan Froyd wrote:
+ /* The PARM is not one we're trying to unify. Just check
+to see if it matches ARG. */
+ int result = !(TREE_CODE (arg) == TREE_CODE (parm)
+ cp_tree_equal (parm, arg));
+ if (result)
+
On 05/25/2011 02:15 PM, Nathan Froyd wrote:
The patch below implements just such an idea. The only twist is that
the `explain' parameter is actually a `location_t *' so that when we
provide explanations that aren't produced via tf_warning_or_error
blocks, the explanations are attached to the
Thanks for the background; I will keep the principle in mind. IMHO, in
a case like this where we're logically printing one diagnostic (one
error and then some number of explanatory notes) keeping all the logic
for the diagnostic centralized makes more sense.
I understand, but that means we
On 05/18/2011 01:45 PM, Jason Merrill wrote:
Thanks for the background; I will keep the principle in mind. IMHO, in
a case like this where we're logically printing one diagnostic (one
error and then some number of explanatory notes) keeping all the logic
for the diagnostic centralized makes
On 05/18/2011 03:00 PM, Nathan Froyd wrote:
Thank you for the review. I'll go back and try things the way you suggest;
before I go off and do that, I've taken your comments to mean that:
- fn_type_unification/type_unification_real and associated callers should take
a boolean `explain'
On 05/09/2011 06:49 PM, Nathan Froyd wrote:
The patch below is an updated version of:
http://gcc.gnu.org/ml/libstdc++/2011-02/msg9.html
Sorry I didn't respond to that message.
In general, my preference is to have diagnostics collocated with the
tests that lead to them, and just run
