From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119393 invoked by alias); 29 Jan 2019 04:37:11 -0000 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 Received: (qmail 119383 invoked by uid 89); 29 Jan 2019 04:37:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=hurt, free!, fighter, que X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Jan 2019 04:37:08 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3D0CEC057E00; Tue, 29 Jan 2019 04:37:07 +0000 (UTC) Received: from free.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EA8B316EEF; Tue, 29 Jan 2019 04:37:06 +0000 (UTC) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTP id x0T4aq8i035046; Tue, 29 Jan 2019 02:36:53 -0200 From: Alexandre Oliva To: Jason Merrill Cc: gcc-patches List , Nathan Sidwell Subject: Re: [C++ PATCH] [PR87770] test partial specializations for type dependence References: <8ed76629-270c-d7ea-e0c1-e351ee31389b@redhat.com> <30dfbac2-066c-6cc5-dff5-18943d843bad@redhat.com> Date: Tue, 29 Jan 2019 08:24:00 -0000 In-Reply-To: (Jason Merrill's message of "Sat, 26 Jan 2019 22:59:00 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-01/txt/msg01655.txt.bz2 On Jan 27, 2019, Jason Merrill wrote: >> + tinfo =3D DECL_TEMPLATE_INFO (node); > Maybe use get_template_info? Neat! But then, if we can assume node is a decl, we might as well go straight for DECL_TEMPLATE_INFO. I'd rather not make that assumption, though, and allow this new function to be called for template types as well, because you mentioned other places that used PRIMARY_TEMPLATE_P might need the extra logic. I don't know whether they might be dealing with types though. >> + ??? How do we >> + tell apart a partial from a full explicit specialization in a >> + non-template context? */ > We don't need to tell them apart here, the caller checks if there are > any dependent template arguments. The single caller does, indeed, but the function does not make that a requirement, so others might call it and fail to check it. Should that test be moved here too? Anyhow, the question was really about the fact that the non-template context has no template argument depth for us to compare with. When I wrote that comment, I was returning true for !ctinfo, unconditionally, reasoning that if NODE's context is not a template, then NODE must specialize some a primary template. But if we want partial but not full explicit specializations, then just having a deeper (or nonzero) template argument depth is not enough, is it? >> + tree ctxt; >> + if (!DECL_P (node)) >> + ctxt =3D TYPE_CONTEXT (node); >> + else >> + ctxt =3D DECL_CONTEXT (node); > We know tmpl is a decl, so we can unconditionally take its DECL_CONTEXT. Does it hurt too much to keep it more general, so that it can deal with template class types too? Or is there going to be no use for that? In the latter case, I suppose we should document that, and then we just use tinfo =3D DECL_TEMPLATE_INFO (node) above (right?) > And you can use get_template_info here as well. *nod*, thanks --=20 Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jam=C3=A1s-GNUChe