[libc++] Work around dynamic linking of stringstream::str() on Windows

[pfusik]

Summary

Also istringstream::str() and ostringstrem::str().

https://github.com/llvm/llvm-project/issues/40363 causes str()
to be dllimport'ed despite _LIBCPP_HIDE_FROM_ABI.
This is a temporary solution until #40363 is fixed.

[pfusik]

Fixes link failures reported by @thakis at https://reviews.llvm.org/D153709

[thakis]

Thanks!

We should merge this (and D155185 if it isn't yet) to the LLVM 17 branch too.

[thakis]

(This needs approval from a libc++ owner as well.)

[thakis]

For libc++ owners: note that this is virtually the same change as 8ecb9591646d4b0326ea7547b99d300336c6c423

[pfusik]

In D157602#4576735, @thakis wrote:

(and D155185 if it isn't yet) to the LLVM 17 branch too.

D155185 was merged before branching 17.x.

[mstorsjo]

What differs in the real world deployments vs what's tested in the libcxx CI; what test config would be needed to catch this in the CI?

[philnik]

In D157602#4578069, @mstorsjo wrote:

What differs in the real world deployments vs what's tested in the libcxx CI; what test config would be needed to catch this in the CI?

I think we'd just have to test older C++ versions on windows. Also note that this is fundamentally a Clang bug that we are working around here.

[pfusik]

What differs in the real world deployments vs what's tested in the libcxx CI; what test config would be needed to catch this in the CI?

Good question! I can't reproduce it on my machine with:

clang version 16.0.5
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/mingw64/bin

@thakis What exact compiler and linker do you use? Can you post a minimal reproducer?

I think we'd just have to test older C++ versions on windows. Also note that this is fundamentally a Clang bug that we are working around here.

Do you mean pre-C++20 standards?

[thakis]

In D157602#4579587, @pfusik wrote:

What differs in the real world deployments vs what's tested in the libcxx CI; what test config would be needed to catch this in the CI?

Good question! I can't reproduce it on my machine with:

clang version 16.0.5
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/msys64/mingw64/bin

@thakis What exact compiler and linker do you use?

clang-cl and lld as downloaded by https://source.chromium.org/chromium/chromium/src/+/main:tools/clang/scripts/update.py;l=12?q=update.py%20file:clang&ss=chromium (which are regular clang and lld as built at rev llvmorg-18-init-1174-g2532b68f).

Can you post a minimal reproducer?

Can you post the one you tried as starting point? I'll try to tweak it then.

[thakis]

Here's an unreduced compiler invocation: https://bugs.chromium.org/p/chromium/issues/detail?id=1463881#c9

@hans Hmm, I wonder if it's related to /Zc:dllexportInlines- (ref https://blog.llvm.org/2018/11/30-faster-windows-builds-with-clang-cl_14.html). We use that, and we build libc++ with -std=c++20 (since it wants that), and we built the client code that had problems with -std=c++17.

[Mordante]

In D157602#4576735, @thakis wrote:

Thanks!

We should merge this (and D155185 if it isn't yet) to the LLVM 17 branch too.

@pfusik can you make a backport request or do you need assistance?

[pfusik]

Can you post the one you tried as starting point? I'll try to tweak it then.

C:\0\src\llvm-project>git co 090996~1
HEAD is now at 1e22873ef4b2 [AMDGPU][NFC] Rename two LIT test files

C:\0\src\llvm-project>ninja -C build cxx
ninja: Entering directory `build'
ninja: no work to do.

C:\0\src\llvm-project>cd ..

C:\0\src>cat strwin.cpp
#include <iostream>
#include <sstream>

int main() {
  std::cout << std::stringstream("hi").str();
}

C:\0\src>clang++ -std=c++11 -fuse-ld=ld -o strwin.exe strwin.cpp -nostdinc++ -I llvm-project/build/include/c++/v1 llvm-project/build/lib/libc++.dll.a

C:\0\src>.\strwin.exe
hi

@pfusik can you make a backport request or do you need assistance?

My only concern is that we have no test. What's the schedule for the next 17.0 RC ?

[mstorsjo]

In D157602#4580154, @thakis wrote:

@hans Hmm, I wonder if it's related to /Zc:dllexportInlines- (ref https://blog.llvm.org/2018/11/30-faster-windows-builds-with-clang-cl_14.html). We use that, and we build libc++ with -std=c++20 (since it wants that), and we built the client code that had problems with -std=c++17.

Right, this rings some bells.

I ran into similar issues before - see b048397db8027fedf9380e7cf9213239d558fa29 / https://reviews.llvm.org/D122718, for an issue caused by the fact that in the default config, the library is built with -std=c++20 but the tests are compiled with -std=c++2b. I guess we ideally should test with running the tests for a few c++ versions at least, to check for more instances of this issue.

[hans]

In D157602#4580154, @thakis wrote:

@hans Hmm, I wonder if it's related to /Zc:dllexportInlines- (ref https://blog.llvm.org/2018/11/30-faster-windows-builds-with-clang-cl_14.html).

I don't think that's a factor here.

I can't reproduce it on my machine with

Is your libcxx configured with -DLIBCXX_ABI_UNSTABLE=ON? The explicit instantiations are gated by _LIBCPP_ABI_ENABLE_ADDITIONAL_IOSTREAM_EXPLICIT_INSTANTIATIONS_1

On my machine, the source code and revision you used reproduces the problem like this:

cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS='clang;lld' -DLLVM_ENABLE_RUNTIMES='libcxx' -DLLVM_TARGETS_TO_BUILD=X86 -DLIBCXX_ABI_UNSTABLE=ON ..\llvm
ninja cxx
bin\clang-cl /std:c++17 \src\temp\strwin.cpp -Iinclude\c++\v1 lib\c++.lib
strwin-b8a36d.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::__2::basic_string<char,struct std::__2::char_traits<char>,class std::__2::allocator<char> > __cdecl std::__2::basic_stringstream<char,struct std::__2::char_traits<char>,class std::__2::allocator<char> >::str(void)const " (__imp_?str@?$basic_stringstream@DU?$char_traits@D@__2@std@@V?$allocator@D@23@@__2@std@@QEBA?AV?$basic_string@DU?$char_traits@D@__2@std@@V?$allocator@D@23@@23@XZ) referenced in function main
strwin.exe : fatal error LNK1120: 1 unresolved externals
clang-cl: error: linker command failed with exit code 1120 (use -v to see invocation)

[pfusik]

In D157602#4592023, @hans wrote:

Is your libcxx configured with -DLIBCXX_ABI_UNSTABLE=ON?

Tried this now. This alone does not trigger the problem in my config, but there are several other differences between my and your commands to check.

I will backport my fix later today.

libcxx/include/sstream

 #if _LIBCPP_STD_VER >= 20
     template <class _SAlloc>
       requires __is_allocator<_SAlloc>::value
     _LIBCPP_HIDE_FROM_ABI basic_string<char_type, traits_type, _SAlloc> str(const _SAlloc& __sa) const {
         return basic_string<_CharT, _Traits, _SAlloc>(view(), __sa);
     }
 
     _LIBCPP_HIDE_FROM_ABI basic_string_view<char_type, traits_type> view() const noexcept;
-#endif
+#endif // _LIBCPP_STD_VER >= 20
 
     void str(const string_type& __s) {
         __str_ = __s;
         __init_buf_ptrs();
     }
 
 #if _LIBCPP_STD_VER >= 20
     template <class _SAlloc>
#endif // _LIBCPP_STD_VER >= 20
     }
 
     // [istringstream.members] Member functions:
     _LIBCPP_INLINE_VISIBILITY
     basic_stringbuf<char_type, traits_type, allocator_type>* rdbuf() const {
         return const_cast<basic_stringbuf<char_type, traits_type, allocator_type>*>(&__sb_);
     }
 
-#if _LIBCPP_STD_VER >= 20
-    _LIBCPP_HIDE_FROM_ABI string_type str() const & { return __sb_.str(); }
+#if _LIBCPP_STD_VER <= 17 || defined(_LIBCPP_BUILDING_LIBRARY)
+    _LIBCPP_HIDE_FROM_ABI string_type str() const { return __sb_.str(); }
+#else
+    _LIBCPP_HIDE_FROM_ABI_SSTREAM string_type str() const & { return __sb_.str(); }
+
+    _LIBCPP_HIDE_FROM_ABI_SSTREAM string_type str() && { return std::move(__sb_).str(); }
+#endif
 
+#if _LIBCPP_STD_VER >= 20
     template <class _SAlloc>
       requires __is_allocator<_SAlloc>::value
     _LIBCPP_HIDE_FROM_ABI basic_string<char_type, traits_type, _SAlloc> str(const _SAlloc& __sa) const {
         return __sb_.str(__sa);
     }
 
-    _LIBCPP_HIDE_FROM_ABI string_type str() && { return std::move(__sb_).str(); }
-
     _LIBCPP_HIDE_FROM_ABI basic_string_view<char_type, traits_type> view() const noexcept { return __sb_.view(); }
-#else // _LIBCPP_STD_VER >= 20
-    _LIBCPP_HIDE_FROM_ABI string_type str() const { return __sb_.str(); }
 #endif // _LIBCPP_STD_VER >= 20
 
     _LIBCPP_HIDE_FROM_ABI void str(const string_type& __s) { __sb_.str(__s); }
 
 #if _LIBCPP_STD_VER >= 20
     template <class _SAlloc>
     _LIBCPP_HIDE_FROM_ABI void str(const basic_string<char_type, traits_type, _SAlloc>& __s) {
         __sb_.str(__s);
#endif // _LIBCPP_STD_VER >= 20
     }
 
     // [ostringstream.members] Member functions:
     _LIBCPP_INLINE_VISIBILITY
     basic_stringbuf<char_type, traits_type, allocator_type>* rdbuf() const {
         return const_cast<basic_stringbuf<char_type, traits_type, allocator_type>*>(&__sb_);
     }
 
-#if _LIBCPP_STD_VER >= 20
-    _LIBCPP_HIDE_FROM_ABI string_type str() const & { return __sb_.str(); }
+#if _LIBCPP_STD_VER <= 17 || defined(_LIBCPP_BUILDING_LIBRARY)
+    _LIBCPP_HIDE_FROM_ABI string_type str() const { return __sb_.str(); }
+#else
+    _LIBCPP_HIDE_FROM_ABI_SSTREAM string_type str() const & { return __sb_.str(); }
 
+    _LIBCPP_HIDE_FROM_ABI_SSTREAM string_type str() && { return std::move(__sb_).str(); }
+#endif
+
+#if _LIBCPP_STD_VER >= 20
     template <class _SAlloc>
       requires __is_allocator<_SAlloc>::value
     _LIBCPP_HIDE_FROM_ABI basic_string<char_type, traits_type, _SAlloc> str(const _SAlloc& __sa) const {
         return __sb_.str(__sa);
     }
 
-    _LIBCPP_HIDE_FROM_ABI string_type str() && { return std::move(__sb_).str(); }
-
     _LIBCPP_HIDE_FROM_ABI basic_string_view<char_type, traits_type> view() const noexcept { return __sb_.view(); }
-#else // _LIBCPP_STD_VER >= 20
-    _LIBCPP_HIDE_FROM_ABI string_type str() const { return __sb_.str(); }
 #endif // _LIBCPP_STD_VER >= 20
 
     _LIBCPP_HIDE_FROM_ABI void str(const string_type& __s) { __sb_.str(__s); }
 
 #if _LIBCPP_STD_VER >= 20
     template <class _SAlloc>
     _LIBCPP_HIDE_FROM_ABI void str(const basic_string<char_type, traits_type, _SAlloc>& __s) {
         __sb_.str(__s);
#endif // _LIBCPP_STD_VER >= 20
     }
 
     // [stringstream.members] Member functions:
     _LIBCPP_INLINE_VISIBILITY
     basic_stringbuf<char_type, traits_type, allocator_type>* rdbuf() const {
         return const_cast<basic_stringbuf<char_type, traits_type, allocator_type>*>(&__sb_);
     }
 
-#if _LIBCPP_STD_VER >= 20
-    _LIBCPP_HIDE_FROM_ABI string_type str() const & { return __sb_.str(); }
+#if _LIBCPP_STD_VER <= 17 || defined(_LIBCPP_BUILDING_LIBRARY)
+    _LIBCPP_HIDE_FROM_ABI string_type str() const { return __sb_.str(); }
+#else
+    _LIBCPP_HIDE_FROM_ABI_SSTREAM string_type str() const & { return __sb_.str(); }
+
+    _LIBCPP_HIDE_FROM_ABI_SSTREAM string_type str() && { return std::move(__sb_).str(); }
+#endif
 
+#if _LIBCPP_STD_VER >= 20
     template <class _SAlloc>
       requires __is_allocator<_SAlloc>::value
     _LIBCPP_HIDE_FROM_ABI basic_string<char_type, traits_type, _SAlloc> str(const _SAlloc& __sa) const {
         return __sb_.str(__sa);
     }
 
-    _LIBCPP_HIDE_FROM_ABI string_type str() && { return std::move(__sb_).str(); }
-
     _LIBCPP_HIDE_FROM_ABI basic_string_view<char_type, traits_type> view() const noexcept { return __sb_.view(); }
-#else // _LIBCPP_STD_VER >= 20
-    _LIBCPP_HIDE_FROM_ABI string_type str() const { return __sb_.str(); }
 #endif // _LIBCPP_STD_VER >= 20
 
     _LIBCPP_HIDE_FROM_ABI void str(const string_type& __s) { __sb_.str(__s); }
 
 #if _LIBCPP_STD_VER >= 20
     template <class _SAlloc>
     _LIBCPP_HIDE_FROM_ABI void str(const basic_string<char_type, traits_type, _SAlloc>& __s) {
         __sb_.str(__s);