From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id F038E3857C48 for ; Mon, 16 May 2022 17:04:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F038E3857C48 Received: by mail-wm1-x333.google.com with SMTP id 1-20020a05600c248100b00393fbf11a05so11310724wms.3 for ; Mon, 16 May 2022 10:04:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=kNzoOLpLEUY0/rShhSP9tprvVzuBu5jrK9Se8rVT42U=; b=4GhAvZLnsBzbjZDrlVNtXNdVLHZ0VTCkX21GD7sSl0Whd3jk1zprl5910pmj7buhaS EDfU/kSmmFqY5qfaQMU2d5svCDPFspLQeoh1LY7L/ufW58bW/4alqjor836F6dZF77se k/LSCX1Sp/TJFU9UHdvDYBB3JOSgPW2iHynjSrsRgWGRYCUKeAFp6mjg9244oz7XLYow dW2wHh1E4MomeJe8DawXSPk2QIDgjxQneeOKQYqYHNggN9i4+CSTO8j9Dv84c/CTo13w wfDDokMs5AB16Qh3OGn/huBFwA71/yFfP4LkvnYfqLk7nXg3Hb3ZqbqJYIwrW39WvPCe H9jw== X-Gm-Message-State: AOAM5323aXVE46Ie/m9mVK2o1w/4A+1NA50HZPI1ylgkAanTAtBm9he3 Q3+3hOjIKd78gFrvy4LLEWA= X-Google-Smtp-Source: ABdhPJyzZlK/hfSDOyMq/w+XxTbZHtjjmCAM6uWZzfXZB9LQq+V9GizHxMivzy+LNFDS6+hQQGyiOg== X-Received: by 2002:a7b:c114:0:b0:394:47d3:693f with SMTP id w20-20020a7bc114000000b0039447d3693fmr28995101wmi.42.1652720653521; Mon, 16 May 2022 10:04:13 -0700 (PDT) Received: from [10.13.0.77] ([109.190.253.11]) by smtp.googlemail.com with ESMTPSA id h28-20020adfaa9c000000b0020d02ddf4d5sm2834019wrc.5.2022.05.16.10.04.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 May 2022 10:04:13 -0700 (PDT) Message-ID: <885f26d0-3208-cbe0-6429-69d2862cbfbf@gmail.com> Date: Mon, 16 May 2022 19:04:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [committed 03/12] libstdc++: Add macros for the inline namespace std::_V2 Content-Language: fr To: Jonathan Wakely Cc: libstdc++ References: <20220513124050.4028450-1-jwakely@redhat.com> <20220513124050.4028450-3-jwakely@redhat.com> <65a5eb4c-8c9e-4bc6-846a-a06b1f6d5c1e@gmail.com> <005d0911-4fb6-f14a-a23a-2ff26774bfd6@gmail.com> From: =?UTF-8?Q?Fran=c3=a7ois_Dumont?= In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2022 17:04:16 -0000 On 16/05/22 18:19, Jonathan Wakely wrote: > On Mon, 16 May 2022 at 05:28, François Dumont via Libstdc++ > wrote: >> Based on what you told me recently maybe this patch is better. It does >> not change the link errors. > We need to be a little careful about just removing those macros. > > For definitions that use qualified names, the macros are not needed. > For example: > > namespace std { inline namespace __8 { > struct foo { > void bar(); // #1 > }; > } } > > namespace std { > void foo::bar() { } // #2 > } > > The definition at #2 works correctly, because name lookup for 'foo' > finds std::__8::foo, so it's a definition of the member declared at > #1. > > But if we have a definition using an unqualified name, that doesn't > work the same. For example: > > namespace std { inline namespace __8 { > void func(); // #3 > } } > > namespace std { > void func() { } // #4 > } > > The definition at #4 doesn't need to do any name lookup, so it just > defines (and declares) a new function directly in namespace std. This > means we have std::__8::func declared at #3 and std::func declared at > #4, and so trying to call std::func() would be ambiguous. > > So we don't need to _add_ the macros to files where the symbols are > already being defined correctly (which is why your recent patch was > not needed). And we can remove them from _some_ source files. But if > we remove all source files, some of those removals would be wrong. > And thanks for this explanation too, I wasn't considering all use cases indeed. So no rush to do any cleanup, good.