[CMake][Fuchsia] Use unstable libc++ ABI for Fuchsia toolchain

[phosek]

Summary

We don't need to provide stable ABI and hence we can use the unstable
one and take an advantage of all the new features.

[mcgrathr]

lgtm

[kristina]

LGTM. Can we formalize ABIv2 as stable and make it distinct from unstable (soon to be ABIv3) or are there are any rough corners still left before ABIv2 and unstable can split in a feature freeze? I'm not an expert on libc++ related matters but @ldionne suggested that ABIv2 still wasn't ready on IRC (unless I misunderstood him).

[ldionne]

In D52660#1249709, @kristina wrote:

LGTM. Can we formalize ABIv2 as stable and make it distinct from unstable (soon to be ABIv3) or are there are any rough corners still left before ABIv2 and unstable can split in a feature freeze? I'm not an expert on libc++ related matters but @ldionne suggested that ABIv2 still wasn't ready on IRC (unless I misunderstood him).

I don't think we've ever had plans to freeze the ABI v2 into something stable -- this is the first time I hear about it. I'm not saying it does not make sense, by the way, just that I haven't heard any plans about this. Does Fuchsia have a desire to stabilize the ABI of libc++?

[jakehehrlich]

We have no such desire. I think we're fine being the test subjects for
ABIv2 however.

[kristina]

My misunderstanding then, I was eventually hoping for a feature freeze of ABIv2 to a point where it's considered stable so any alterations to things like internal layout of std::string (ie. like SBO that came with ABIv2) happen in unstable/std::__3 as this allows for major ABI breaking changes to slowly start integrating into various other downstream projects. If it remains unstable then there is more hesitation when it comes to vendors switching ABIs; perhaps in a major OS release, while still providing ABIv1 libraries for compatibility. I'm not really involved in libc++ evolution but it seems logical that adoption of ABIv2 should begin somewhere (even if Fuchisa remains on unstable for the time being) since it does bring notable benefits.

In D52660#1249761, @ldionne wrote:

I don't think we've ever had plans to freeze the ABI v2 into something stable -- this is the first time I hear about it. I'm not saying it does not make sense, by the way, just that I haven't heard any plans about this. Does Fuchsia have a desire to stabilize the ABI of libc++?

Well as I said, I have no say in how C++ language or standards or libc++(abi) evolve, but it seems to be the next logical step (though perhaps it could wait until Clang 8 and C++20 since that may require breaking changes which make sense to do within ABIv2 while it's still unstable). Otherwise aside from unreleased operating systems, having it formalized may encourage downstream vendors, especially Linux based ones, where fragmentation is normal to slowly begin adopting it.

Anyway, sorry for straying offtopic, patch itself LG.

clang/cmake/caches/Fuchsia-stage2.cmake

if(LINUX_${target}_SYSROOT)
       set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_ENABLE_SHARED OFF CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_LIBCXXABI_INSTALL_LIBRARY OFF CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_LIBCXX_USE_COMPILER_RT ON CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_LIBCXX_ENABLE_SHARED OFF CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
+      set(RUNTIMES_${target}-linux-gnu_LIBCXX_ABI_UNSTABLE ON CACHE BOOL "")
+      # TODO: this is a workaround for PR39053 which was uncovered by D50652.
+      set(RUNTIMES_${target}-linux-gnu_LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT ON CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_SANITIZER_CXX_ABI "libc++" CACHE STRING "")
       set(RUNTIMES_${target}-linux-gnu_SANITIZER_CXX_ABI_INTREE ON CACHE BOOL "")
       set(RUNTIMES_${target}-linux-gnu_COMPILER_RT_USE_BUILTINS_LIBRARY ON CACHE BOOL "")
     endif()
   endforeach()
 endif()
 
 if(FUCHSIA_SDK)
foreach(target x86_64;aarch64)
     set(RUNTIMES_${target}-fuchsia_LIBCXXABI_USE_COMPILER_RT ON CACHE BOOL "")
     set(RUNTIMES_${target}-fuchsia_LIBCXXABI_USE_LLVM_UNWINDER ON CACHE BOOL "")
     set(RUNTIMES_${target}-fuchsia_LIBCXXABI_ENABLE_STATIC_UNWINDER ON CACHE BOOL "")
     set(RUNTIMES_${target}-fuchsia_LIBCXXABI_INSTALL_STATIC_LIBRARY OFF CACHE BOOL "")
     set(RUNTIMES_${target}-fuchsia_LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY OFF CACHE BOOL "")
     set(RUNTIMES_${target}-fuchsia_LIBCXX_USE_COMPILER_RT ON CACHE BOOL "")
     set(RUNTIMES_${target}-fuchsia_LIBCXX_ENABLE_STATIC_ABI_LIBRARY ON CACHE BOOL "")
     set(RUNTIMES_${target}-fuchsia_LIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY OFF CACHE BOOL "")
+    set(RUNTIMES_${target}-fuchsia_LIBCXX_ABI_UNSTABLE ON CACHE BOOL "")
     # TODO: this is a workaround for PR39053 which was uncovered by D50652.
     set(RUNTIMES_${target}-fuchsia_LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT ON CACHE BOOL "")
   endforeach()
 
   set(LLVM_RUNTIME_SANITIZERS "Address" CACHE STRING "")
   set(LLVM_RUNTIME_SANITIZER_Address_TARGETS "x86_64-fuchsia;aarch64-fuchsia" CACHE STRING "")
 endif()