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 0B563385840D for ; Fri, 3 Dec 2021 22:38:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0B563385840D Received: from mail-yb1-f199.google.com (mail-yb1-f199.google.com [209.85.219.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-543-gszvpLlHNjKVQ9myQiv-wQ-1; Fri, 03 Dec 2021 17:38:34 -0500 X-MC-Unique: gszvpLlHNjKVQ9myQiv-wQ-1 Received: by mail-yb1-f199.google.com with SMTP id t1-20020a5b03c1000000b005f6ee3e97easo8735342ybp.16 for ; Fri, 03 Dec 2021 14:38:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p9eeJMcYaGQ/2lw6sdSpZowMc8CmEqXwzR4kDgrKWsY=; b=s+XuOx1hDZwtO/QtKfc8u45y7ACdLgFIn1sFwDZSHFDr6gz2dNxgk+H/rCTWfsZJi2 U7IiVka6rrN7Xz67d3AQH25ULOnzXUljwfuMtj7MVvFSgrbUZSbvWsuW8NHRLeuBxhIs vWqJbojfLl+nYLq9UK3nBYq66aRwSu7gHc1iHw4J7bbWDz0d9xG+0Bhfw3NbcZawdGNj bXF4OqqbVIvMB0zklkefzRsQU3jm6402lsE2sQcO6jWf0VKuWUOPmq3t9clFdhM7qTPV 7aQa3VCmDAHp2JXaPU9bwNnrQSjN1gX0OItcZ7qZOsjwJUwziWJPYLtRJJyagsCmyLVu mbxA== X-Gm-Message-State: AOAM530EzmGq4rHH/h3XOKCi8eDKiMBw1NAFM+c/lED4eKy/h3NKaigC 3VrzJZL62nePXzN1xY0IvLSmtQj+lm1jVr9qlrdkGBZ9kEImbuOFg/wsQhh/Nx6GYwEMOYzvId8 6H5KrWZTTnVaU749NEUkbiUccZ78gDWY= X-Received: by 2002:a25:bcc9:: with SMTP id l9mr26120335ybm.13.1638571113812; Fri, 03 Dec 2021 14:38:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJx5slYek0mYOecWajXDSLdD23+yI8Aq1EQq69Vq+7/nfZTBC1vMtu4qT50Sp2NPwzi3sWnFhzwF8pDv6k9YwkQ= X-Received: by 2002:a25:bcc9:: with SMTP id l9mr26120319ybm.13.1638571113588; Fri, 03 Dec 2021 14:38:33 -0800 (PST) MIME-Version: 1.0 References: <3292e732-f4ff-d80c-d29e-e3a99a0fe3d5@redhat.com> In-Reply-To: <3292e732-f4ff-d80c-d29e-e3a99a0fe3d5@redhat.com> From: Jonathan Wakely Date: Fri, 3 Dec 2021 22:38:22 +0000 Message-ID: Subject: Re: std::basic_string<_Tp> constructor point of instantiation woes? To: Stephan Bergmann Cc: "libstdc++" , gcc Patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Fri, 03 Dec 2021 22:38:41 -0000 On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++ wrote: > > When using recent libstc++ trunk with Clang in C++20 mode, > std::u16string literals as in > > > #include > > int main() { > > using namespace std::literals; > > u""s; > > } > > started to cause linker failures due to undefined > > > _ZNSt7__cxx1112basic_stringIDsSt11char_traitsIDsESaIDsEE12_M_constructIPKDsEEvT_S8_St20forward_iterator_tag > > After some head scratching, I found the more insightful > > > $ cat test.cc > > #include > > constexpr std::string s("", 0); > > > $ clang++ -std=c++20 -fsyntax-only test.cc > > test.cc:2:23: error: constexpr variable 's' must be initialized by a constant expression > > constexpr std::string s("", 0); > > ^~~~~~~~ > > ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:620:2: note: undefined function '_M_construct' cannot be used in a constant expression > > _M_construct(__s, __s + __n, std::forward_iterator_tag()); > > ^ > > test.cc:2:23: note: in call to 'basic_string(&""[0], 0, std::allocator())' > > constexpr std::string s("", 0); > > ^ > > ~/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/basic_string.h:331:9: note: declared here > > _M_construct(_FwdIterator __beg, _FwdIterator __end, > > ^ > > 1 error generated. > > and after some more head scratching found Clang to complain about the > reduced > > > template struct S { > > constexpr void f(); > > constexpr S() { f(); }; > > }; > > S s1; > > template constexpr void S::f() {} > > constexpr S s2; > > (about which GCC does not complain). Not entirely sure who is right, > but what would help Clang is to move the definitions of the literal > operators in basic_string.h (which implicitly instantiate the > corresponding std::basic_string<_Tp> constructor) past the definition of > _M_construct (which is called from the constructor) in basic_string.tcc; > something like The .tcc files are something of an anachronism, as I think they were supposed to have the non-inline function definitions which might be subject to 'export' for separate compilation. Except that feature was removed from C++11, and so now it's just a fairly pointless separation between inline and non-inline functions ... except where we're muddied the waters by changing some to 'inline' without moving them to the other file (because why bother). That said, all the one- or two-line inline functions like the literal operators and to_string are all in basic_string.h and having to move some arbitrary subset of them into the other file, after the non-inline definitions, is a bit annoying. I think this is https://bugs.llvm.org/show_bug.cgi?id=24128