Re: std::basic_string<_Tp> constructor point of instantiation woes?

[Jonathan Wakely <jwakely@redhat.com>]

On Fri, 3 Dec 2021 at 22:38, Jonathan Wakely wrote:
>
> On Mon, 22 Nov 2021 at 16:31, Stephan Bergmann via Libstdc++
> <libstdc++@gcc.gnu.org> wrote:
> >
> > When using recent libstc++ trunk with Clang in C++20 mode,
> > std::u16string literals as in
> >
> > > #include <string>
> > > 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 <string>
> > > 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<const char *>' 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<char>())'
> > > 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<typename> struct S {
> > >     constexpr void f();
> > >     constexpr S() { f(); };
> > > };
> > > S<void> s1;
> > > template<typename T> constexpr void S<T>::f() {}
> > > constexpr S<void> 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

Which is now https://github.com/llvm/llvm-project/issues/24502