From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20117 invoked by alias); 10 May 2011 20:08:46 -0000 Received: (qmail 20109 invoked by uid 22791); 10 May 2011 20:08:44 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 May 2011 20:08:28 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p4AK8LpU024673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 10 May 2011 16:08:21 -0400 Received: from [127.0.0.1] (ovpn-113-60.phx2.redhat.com [10.3.113.60]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p4AK8KtN030189; Tue, 10 May 2011 16:08:21 -0400 Message-ID: <4DC99B34.7070301@redhat.com> Date: Tue, 10 May 2011 23:29:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110421 Fedora/3.1.9-2.fc14 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Nathan Froyd CC: gcc-patches@gcc.gnu.org Subject: Re: [PATCH,c++] describe reasons for function template overload resolution failure References: <20110509224933.GR23480@codesourcery.com> In-Reply-To: <20110509224933.GR23480@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-05/txt/msg00795.txt.bz2 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/msg00009.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 through the same code a second time if we decide that we want to give a diagnostic. For instance, that's what I did in joust and synthesized_method_walk. Saving information ahead of time about why we reject a particular candidate creates overhead that is useless in the vast majority of cases, since most compiles succeed. That said, I'm not going to reject this patch over this issue, but please keep this principle in mind with future diagnostic improvement patches. > + case ur_invalid_arg: > + case ur_invalid_parm: > + case ur_invalid_init_list: > + case ur_invalid_template_parm: > + inform (loc, " an error occurred during template argument deduction"); These are all cases of bailing out when we encounter an error_mark_node that indicates an earlier error from an ill-formed expression or whatever. I don't see any reason to have separate cases for them, and the message is misleading; the error didn't occur during deduction, it occurred before we got to deduction. We just can't do deduction on ill-formed inputs. > + case ur_type_mismatch: > + case ur_pointer_mismatch: > + case ur_reference_mismatch: > + inform (loc, " mismatched types %qT and %qT", Why make these different? They are all cases of the argument and parameter types not having the same form. > + case ur_expanding_pack_to_fixed_arg_list: This is never generated anywhere. And the message in coerce_template_parms is a sorry to indicate that this is a bug in G++, not a problem with the user's code. > unify_failure (struct unification_info *ui, tree parm) ... > return unify_failure (ui); This doesn't compile. Were you testing a previous version of the patch? I guess I'll stop reviewing the patch now and wait for an update. Jason