From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 944A63858D20 for ; Thu, 2 May 2024 18:11:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 944A63858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 944A63858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714673466; cv=none; b=M7MABE/pvVgG1QGAVxyIHvPDLsqkQIx3tqY0nB3BX/cn7UvQGl9PNkLIK+I7PmEINorbHE4Qg2GYQa/2I3U8FMszPe67FI8bL/7l7mYdEMpkzuCsjJ8XSn6OWEpTFVfMVlCfYci9p6s9HdbteM51ltwx9v1Ckfz54Qp+ziI+Ehc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1714673466; c=relaxed/simple; bh=SLjUiDzfgRcdMvRfmdp/4H3yPWW0LeGfl/XMQ03UCM0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=uyo+ylSddYHDNtLCesir9I7p7MLMH0+1nkNM6ZkGCwEathLa2MD1hGh8LwJh+6YTX7fVP69zZ9nS+TNUcYS5/Zk5LCzLjdiPqSCirfSYepd6GeuRzvpoQ96qUSXVZOJo1uIzu78NF6LuruhUtScpfe9PeFYpkE6x45gNU2o+Kcw= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1714673464; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EIOacfa4okUg/zpysqqeiHHy451OraIC8R0s0qZ4rak=; b=aQdS3e55CNR4CsQDVTlNmEqFFSljfbmQnVdvvEUAaGTLIzCP2YuSa1/hcTfpfG1qPzqiBD ofpYVl+h4lYzLhi8zJy45cmpBf9Xxc+zcNvoPZmDCBg8cvhocAVZd7/wQHfdIs0myBXCg7 ToKHsD8KyCYEX9GkgdqZ/653xDhnTKs= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-372-yiMAGNK0O36HaoBFxjoe6g-1; Thu, 02 May 2024 14:11:02 -0400 X-MC-Unique: yiMAGNK0O36HaoBFxjoe6g-1 Received: by mail-qt1-f198.google.com with SMTP id d75a77b69052e-439fcfca0a7so110946811cf.3 for ; Thu, 02 May 2024 11:11:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714673462; x=1715278262; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EIOacfa4okUg/zpysqqeiHHy451OraIC8R0s0qZ4rak=; b=Qz+GAoiTFDMPY9Ma2veXdhXDLgbrwEC16LJSlQfjl9o/kqE7Kt/RNp3F/RpguVZsLO R6dsntfmhnkxHR11165hlaZHzdrDhWsaM5syJ7gY59ftxb5415aEXl96zfnmKCicTowd bnZfmkY7CeQyv7a5Alsw+Bpg3jBVLBWpwcjC53ZftCLH8gQ8qKgi0C5F+LxmJ+k1fRyB 6ZMBqdA/W8kdSIHSWMxDSLGsrDMbF+ssFVYbk1Fanq5W4D4X3PgtVyFP19Sff4OzzLti MPehksbhY0U7Ak0A1P8fCDb8H/SPoYUVrHHwYkIGHdwZb3EnIosVjdLUMJ6b6+oZVuyY 0fQw== X-Gm-Message-State: AOJu0YzlmTEUTJrmt9Np+cXjqs+yMDUhKthjgmZvJQXrl9fWozJefXSj RJK/leBsMfGjRuDYTVesBF981VKnBfWPJcy1Sv+nAnyxzUOJImicPQm2czroOTU5p9kOpBGUxJq v4FzsDvvUZ82QCyWBR02ErXmYBO9TZNaAI3OiiE4QjUFVDc2Tf4zxCPqzSWXALHE= X-Received: by 2002:a05:622a:5488:b0:43a:be1d:df59 with SMTP id ep8-20020a05622a548800b0043abe1ddf59mr391316qtb.15.1714673462090; Thu, 02 May 2024 11:11:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGCRmXJR3vhLSG7SILYJtq0j/Gh3fNqelGxCsIhznyRxMtn3m3Qd7ohbfm0Yphf6Q0J4YUY5Q== X-Received: by 2002:a05:622a:5488:b0:43a:be1d:df59 with SMTP id ep8-20020a05622a548800b0043abe1ddf59mr391281qtb.15.1714673461482; Thu, 02 May 2024 11:11:01 -0700 (PDT) Received: from [192.168.1.130] (130-44-146-16.s12558.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.146.16]) by smtp.gmail.com with ESMTPSA id dr12-20020a05622a528c00b0043c58b6d941sm692741qtb.42.2024.05.02.11.11.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 May 2024 11:11:00 -0700 (PDT) Message-ID: <684386b1-9516-46bb-b184-cfcd1e67abab@redhat.com> Date: Thu, 2 May 2024 14:11:00 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/2] c++: remove lookup_template_class's entering_scope flag To: Patrick Palka Cc: gcc-patches@gcc.gnu.org References: <20240202194104.317982-1-ppalka@redhat.com> <20240202194104.317982-2-ppalka@redhat.com> <1053294c-b63c-b40b-0ba2-069e2bd615c3@idea> <0182a4aa-cb43-42ec-b8fd-c9a23424d889@redhat.com> <823f5898-02d1-e6a3-8e18-aa3695193a0f@idea> <484205c6-07fe-212b-8e88-73fdbc78b377@idea> From: Jason Merrill In-Reply-To: <484205c6-07fe-212b-8e88-73fdbc78b377@idea> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/2/24 13:49, Patrick Palka wrote: > On Wed, 1 May 2024, Jason Merrill wrote: > >> On 5/1/24 13:40, Patrick Palka wrote: >>> On Wed, 1 May 2024, Jason Merrill wrote: >>> >>>> On 5/1/24 12:41, Patrick Palka wrote: >>>>> On Fri, 2 Feb 2024, Patrick Palka wrote: >>>>> >>>>>> Bootstrapped and regtested on x86_64-pc-linux, does this look like >>>>>> an improvement? This is not a bugfix and barely related to the >>>>>> previous >>>>>> patch, but the previous patch's new use of entering_scope=true >>>>>> motivated >>>>>> me to submit this patch since it seems like a nice simplification. >>>>> >>>>> Ping, now that stage 1 is open. >>>> >>>> Thanks for the ping. The earlier message isn't showing up in Thunderbird >>>> for >>>> some reason, though I see it in the gmail web interface... >>> >>> Ah, weird. No worries, this patch was very much stage 1 material anyway. >>> >>>> >>>>>> @@ -16771,9 +16722,10 @@ tsubst (tree t, tree args, tsubst_flags_t >>>>>> complain, tree in_decl) >>>>>> ctx = TREE_VEC_ELT (ctx, 0); >>>>>> } >>>>>> else >>>>>> - ctx = tsubst_aggr_type (ctx, args, >>>>>> - complain | tf_qualifying_scope, >>>>>> - in_decl, /*entering_scope=*/1); >>>>>> + { >>>>>> + ctx = tsubst_scope (ctx, args, complain, in_decl); >>>> >>>> Why is this one tsubst_scope while the others are all plain tsubst? >>> >>> Ah, just because the call to tsubst_aggr_type being replace passes >>> tf_qualifying_scope already, so we might as well use tsubst_scope >>> as shorthand. >>> >>>> Do we want a tsubst_entering_scope function? >>> >>> Which is just shorthand for tsubst + adjust_type_for_entering_scope? >> >> That's what I was thinking. >> >>> Sure, though I was wondering if we eventually might want to get rid of >>> the distinction between the primary template type A and the generic >>> instantiation A, and we could treat this as an incremental step >>> towards that (then we'd just eventually remove the >>> adjust_type_for_entering_scope calls and keep the tsubst calls). >> >> I don't think we want that; having the distinction helps to avoid wrongly >> looking up members of the primary template in contexts that shouldn't be able >> to. > > Makes sense. How does the following look? > > The name tsubst_entering_scope sounds confusingly similar to > tsubst_scope, but I can't think of a better name for it or for > adjust_type_for_entering_scope :/ > > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc > index 1c3eef60c06..261d6b9f4c8 100644 > --- a/gcc/cp/pt.cc > +++ b/gcc/cp/pt.cc > @@ -185,8 +185,6 @@ static int unify_pack_expansion (tree, tree, tree, > static tree copy_template_args (tree); > static tree tsubst_template_parms (tree, tree, tsubst_flags_t); > static void tsubst_each_template_parm_constraints (tree, tree, tsubst_flags_t); > -static tree tsubst_aggr_type (tree, tree, tsubst_flags_t, tree, int); > -static tree tsubst_aggr_type_1 (tree, tree, tsubst_flags_t, tree, int); > static tree tsubst_arg_types (tree, tree, tree, tsubst_flags_t, tree); > static tree tsubst_function_type (tree, tree, tsubst_flags_t, tree); > static bool check_specialization_scope (void); > @@ -9901,6 +9899,34 @@ maybe_get_template_decl_from_type_decl (tree decl) > ? CLASSTYPE_TI_TEMPLATE (TREE_TYPE (decl)) : decl; > } > > +/* If TYPE is the generic implicit instantiation A, return the primary > + template type A (which is suitable for entering into e.g. for name > + lookup), otherwise return TYPE. */ Maybe "e.g. for defining a member of A" OK either way. > + > +tree > +adjust_type_for_entering_scope (tree type) > +{ > + if (CLASS_TYPE_P (type) > + && dependent_type_p (type) > + && TYPE_TEMPLATE_INFO (type) > + /* We detect the generic implicit instantiation A by inspecting > + TYPE_CANONICAL, which lookup_template_class sets to the primary > + template type A. */ > + && TYPE_CANONICAL (type) == TREE_TYPE (TYPE_TI_TEMPLATE (type))) > + type = TYPE_CANONICAL (type); > + return type; > +}