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.129.124]) by sourceware.org (Postfix) with ESMTPS id 6C9AF3858D1E for ; Mon, 20 May 2024 22:00:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6C9AF3858D1E 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 6C9AF3858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716242416; cv=none; b=YfRg8468tXneAKd8Ga1AhBAzwyuH2qL1NSXGjYTFPIAi5csNM+OhJHH54+98see/Z4Hg2PA8jhl8a5Qex5DrnbtuOnWfYMd428y+za6AkiV8WLyIlVSYrSkMti/R/AD/HRZYKoqlQnz3NYki5qAt1PBtrxEPEGvXgnVCfGVRtXc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716242416; c=relaxed/simple; bh=i29JlXm+J4rjNvtHmUQXEOTB+GkQuqt0dhv57n0AST8=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=PSZ6ELkXLZbDz/nF7XrNOv9ECTL5soVFWCc14FgkvEIZP466k6cjFM3nAo7w/BrQeKCDZwPFdiKVcl0YT0wjjO0iEge8iRAAH0MfOgMEbIU8kjkE5fkHYYHzzOBHM9gkoJGVhgX84MF2mA+7NDQI+cODqfABbFst4ZM5x+VSJ3Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1716242414; 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=jttwAsVNeKUx9wdYXdEhCEeh11ry8O6ZAQTv/6ilGks=; b=VXEBbhziPfZbLtBsSAlBXtibE/aQcUxPM5f9aJFKrcojq/9k49LXV6EBO1W8QqKOWctJ7F toAWANZnEDbOWNENKu8r93bUrGd19z5GoAx7mzjP/UwydX3jMdYvu1UAL0eCh8PpSb9pPF cIty5WmsC5d9zEKq1ZQRdurZ++A9MGA= Received: from mail-ot1-f70.google.com (mail-ot1-f70.google.com [209.85.210.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-531-2XPkpuQzOSCUyaGIKmE25Q-1; Mon, 20 May 2024 18:00:12 -0400 X-MC-Unique: 2XPkpuQzOSCUyaGIKmE25Q-1 Received: by mail-ot1-f70.google.com with SMTP id 46e09a7af769-6f1190504b8so8506651a34.1 for ; Mon, 20 May 2024 15:00:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716242411; x=1716847211; 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=jttwAsVNeKUx9wdYXdEhCEeh11ry8O6ZAQTv/6ilGks=; b=bYbADMjmgzt4JmqGdSG1j56wJZzhgkqUemYu1i9qNbUa3x2SLOurtdhnSK+AuQCrJL W850G16fLGQouQitaj7gXox7Po3eVv0cwFw/IHE0DrOMYD0EXK5kAGmsWG8dfxYnIYsf 3+1pU/BjF7hBtLTBTM91EhpLgnT8wQV2xMAPUY1POSsiIHphXjuO9jsoeLZVV5ni/EWY pVxMhzdwCNVAagdhX6Z8UnLVu4SNeserUS+N2gw5vUp1KcjKNF4+PXKp/1Y+FO3KFF5J O3KeklXoclf0M0H3cRStLXZkKmg58Z9kLPo3ZQVEhr2wJ6qlsx8ubYuo9tkiJWmqTnvd tCbg== X-Gm-Message-State: AOJu0Yy2rWjxZcu2qylAwKkd2dvPeputH7uzOge/BbQcuuWfJHrk6fhs zONDqpshJ6LEU7kJgXyzkOBpija8bi+DTCvSzhaslOC/7OOMb1EqfEiOImlBxrtEi0Xf9LvrclT a//Na2U+04Hu1JMvVfRZ0jEYakxyBCoHtJtOSbqRI9pbLdWmtOBezte0= X-Received: by 2002:a9d:3e49:0:b0:6f0:e813:8809 with SMTP id 46e09a7af769-6f0e90f3a34mr35488544a34.6.1716242411340; Mon, 20 May 2024 15:00:11 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEDz/XKDBnDY9Lw6E6FxR6xuE+tNJFCCB7PJZNRHrtO9KTRB54eNKA0LtFkNhqrZIobhfODpg== X-Received: by 2002:a9d:3e49:0:b0:6f0:e813:8809 with SMTP id 46e09a7af769-6f0e90f3a34mr35488523a34.6.1716242410892; Mon, 20 May 2024 15:00:10 -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 af79cd13be357-7931a60e966sm347567185a.39.2024.05.20.15.00.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 May 2024 15:00:10 -0700 (PDT) Message-ID: Date: Mon, 20 May 2024 18:00:09 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] c++/modules: Remember that header units have CMIs To: Nathaniel Shead Cc: gcc-patches@gcc.gnu.org, Nathan Sidwell References: <664181e2.650a0220.dbfd8.e3d5@mx.google.com> <10d5ff7c-3d30-4317-97d9-91ea2370bbfa@redhat.com> <6646f5cb.170a0220.fb17d.75a5@mx.google.com> From: Jason Merrill In-Reply-To: <6646f5cb.170a0220.fb17d.75a5@mx.google.com> 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=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_WEB,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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/17/24 02:14, Nathaniel Shead wrote: > On Tue, May 14, 2024 at 06:21:48PM -0400, Jason Merrill wrote: >> On 5/12/24 22:58, Nathaniel Shead wrote: >>> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? >> >> OK. >> > > I realised as I was looking over this again that I might have spoken too > soon with the header unit example being supported. Doing the following: > > // a.H > struct { int y; } s; > decltype(s) f(decltype(s)); // { dg-error "used but never defined" } > inline auto x = f({ 123 }); > > // b.C > struct {} unrelated; > import "a.H"; > decltype(s) f(decltype(s) x) { > return { 456 + x.y }; > } > > // c.C > import "linkage-3_a.H"; > int main() { auto a = x.y; } > > Actually does fail to link, because in 'c.C' we call 'f(.anon_0)' but > the definition 'b.C' is f(.anon_1). > > I don't think this is fixable, so I don't think this direction is > workable. Since namespace-scope anonymous types are TU-local, we don't need to support that for proper modules, but it's not clear to me that we don't need to support it for header units. OTOH, https://eel.is/c++draft/module#import-5.3 allows c.C to import a different header unit than b.C, in which case the type is different and x violates the odr. > That said, I think that it might still be worth making header modules > satisfy 'module_has_cmi_p', since that is true to the name, and will be > useful in other places we currently use 'module_p ()': in which case we > could instead make all the callers in 'no_linkage_check' do > 'module_maybe_has_cmi_p () && !header_module_p ()'; something like the > following, perhaps? If we need that condition, it should be its own predicate rather than expecting callers to do that combined check. But it's not clear to me how this is different from a type in the GMF of a named module, which is exactly the maybe_has_cmi case; there we could again see a different version of the type if another TU includes the header. Jason