<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/70820>70820</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
[libc++] Vendor communication: upcoming ABI breaks in std::expected and parts of <ranges>
</td>
</tr>
<tr>
<th>Labels</th>
<td>
libc++
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
ldionne
</td>
</tr>
</table>
<pre>
Hi @llvm/libcxx-vendors,
This issue is not a traditional issue. It is a communication to vendors about upcoming ABI breaks in `std::expected` and some parts of `<ranges>`. It was recently brought to our attention in https://github.com/llvm/llvm-project/issues/70494 (see the associated PR for more discussion) that there is a problem with some of the library's usage of `[[no_unique_address]]`, which can lead to objects overlapping with padding bytes of other objects and their contents being overwritten unexpectedly.
We are aware of this issue in `std::expected` and in `std::__movable_box`, which is used to implement several views in `<ranges>`. Fixing this will require breaking the ABI for the types involved. We introduced `std::expected` and `__movable_box` in LLVM 16 so this has been shipping for two releases. We are aiming to fix these issues in LLVM 18.
Typically, we do not expect code to expose a lot of `<ranges>` views at ABI boundaries, so we believe the `__movable_box` ABI break to have a limited fallout. However, `std::expected` is a vocabulary type and is intended to appear at all kinds of API (and ABI) boundaries, in particular function result types. That ABI break is more likely to cause actual issues in the wild.
At this moment, we want to make vendors aware of these upcoming changes so they can plan ahead and perhaps limit the blast radius in case they haven't shipped LLVM 16/17 yet. One possibility would be to disable `std::expected` in their downstream release or keep it experimental behind `-fexperimental-library`. We will update this thread as we gain more clarity on the exact nature of the upcoming ABI break (e.g. which types are impacted and under what circumstances).
#### FAQ
**Q:** Are you going to allow vendors to opt into the old/new ABI for these types?
**A:** No. The current ABI has correctness issues which are serious enough that nobody should opt into the old ABI. This isn't a performance improvement or a slight conformance fix.
**Q:** Are you going to take this opportunity to enable other ABI breaks, effectively moving to "ABI v2"?
**A:** No. The intent of these changes is to keep the ABI break as narrow as possible with the hopes that the actual fallout will be limited. `<ranges>` is seldom used at ABI boundaries. `std::expected` shipped only recently, requires C++23 and we expect that few users will have had the time to depend on it in their ABI.
**Q:** Is it possible to use some techniques to try and diagnose when folks have an ABI mismatch after shipping that ABI break?
**A:** Yes, to some extent. We will use ABI tags to influence the mangling of functions that contain a type that undergoes an ABI break. This means that trying to link two units using/providing a function whose signature contains e.g. `std::expected` will fail at link time since the mangled name of the function will be different between LLVM 17 and LLVM 18. However, this technique has limitations. For example, if a `std::expected` is contained in a user-defined class, the user-defined class will not get an ABI tag despite its layout potentially changing between LLVM 17 and LLVM 18.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJykV8Fu4zgS_Rr5UmjDkWM7OfjgJGtMgNndmUVjGnsKSmTJ4oYiNSRl2X-_qKJkJ92dzGEAI3Asiqx69d6rIsZoDo5oW6weitXTDPvU-LC12njnaFZ5fd7-YqC4XVh7bItyb02lTqcvR3Lah1iUj8XiqVjs8t-vjYlgYuwJTATnEyCkgNok4x3a_GgOz4kfIyjftr0zCvkxJA_jroCV7xP0nfKtcQfYPTxDFQhfIxgHxXoRky6Wu2K5o1NHKpEu1gtApyH6lqDDkCL4mlcWy8eA7kCxWP6jWC_k7AEjBFLkkj1DFXx_aBKf7vsAmBI5Ccc4aFLqIh9U7otyfzCp6au58gLDiIY9tl-64P9HKhXlXvKLRbnfLG7vb6Eo7yIRpIYAY_TKYCINv_0Hah-g9YFAm6j6GI13RXkPqcHEqwNlfLrgK0stDCY1OTVfy27WVAHDuSg3EfqIB5qy5SI-OP_SO_NnTy-odaAYi9UTf9aLonyEoTGqAYUOLKGWvCsOP4I_UrDYdQy5HNmh1vxPdU4kgHoO7rKeAU8NmQDKO4YtQkW8njcagmEooXdTjex5_pYr3wgwEODAfyWvK3c-L_J3j19eWn_EytJL5U_vkjSMDkmOpu0steQSRDpSQAtHQ8PEpx9YsjcnTkRiGoy1EOjP3gTKNMyPSHjJpeTv6dwRb3f09kh6Dt84jRS87hXpT9Mp1ovvU-Cwfv31j3_CzRqiz2E0yPCSg9iYXCM5evAQyBJGinKoYGpENslDbU4cXaSMbLxufPeuGF_PnVFo7VnAI9Be1JtDBeU18W506nwkQLA-_VxfI6qYsmZ97zQGw5J45EQGgoqsoWMWxc8yv2idD2zwKMeZ1rByarTW92kOv_iBq8i7foSsCOjoFVa9xXCW-mT2MAiJnM7EwK4jZN0DWguvxmlh-u63Z5Yvv7B7eGZxvk_GOLEZo3h3qHunxDQCxd6mTIY5fG0mICQhE7PorXkle-bDFfaMp0r9ZI5SIcZmMFa_K9EuZR60nmk81mlAJ9bV4itd3fMqKa78xUZVI5XKjKKzeEBn0QE27ASca0ehwS5mxCWOymJMwB7eS2wKI-XXuTiuKDcpM5L0RNmi3N9s4ExpDv92BJ2P0VTGmnSGwfdWQyVs0iZy4T-uoBvdRfvBxRQI24nq4AO8EnVgMkeDYUzQQkWNyZL6Ur998GVyTBb3N8qa7juNiTKqqQmCQWRUD2hcLpWyGDhun4tCJ1QJHKb-AvBPuhQTh-aH-ehC2Rm4JKbtkLMTqHunKcDAFFEmqL6NCZ1idt2_q3tRLi8f2O9-n37lz-_SnPgDu0Bw9j0c_Ch91spw4QTbfJeY-VJ88FYX5d7R8NbE4mhjxXL_9pTd9ZR_eWY1gepDYDPll9mYlA-BVHIU48TjnDynHSkY30cgx602dznnebSA2Aghvg-N9-WDpCNkjiFzs_ahZZAYyeCP2dB9AIRoDXdx5d1lTW1O3wH5V5AlVpHQwXedD6l3XHs2PidMze3vOo2wCKmuSSVzZEW3_jjuVJQlLzuWRVn-NZriR-mq2EmoRuomRJ_aTSYYRnAYgh_4W9aXpdyzeWHjmXHTNDH5y-iemfsVTa46_5mNmwiRrPZtbqA_-Pn8Q9VOXuCdPV-mLAZq7KARHovyoSgfyqXIYKCpy0i8NQ18ZBjbrjSABnVusabNxkEdOT6B5X9xCabMp-V-jrz-glbyfFAeqxKpRiYmATyFs4SmDR4cN7yhIQe1t69x7EhO4GhNbDExyetE4dqX0zvb_7j8_82tJPkcBJ2YBW_sKeaSJzxIWMbVtidmNoPRojtYGbbqS_sZa87TGDsY5qYnv4nbHDwbkbvGNmqsJZzeTeE8Utga9yrjBauABynjDkW5Z90ZmQrx2vaGhmHim0S2xjGCCGKDH1FFsqzRWOZXPo4rHM27HEmDw-voez1zpLE2dU1iRhWlgQek3IY2UsNp2Hk7MmTDn0ou_iVakGtInMPeB3Z6nhil1deAn40ZY7IkgykKe79oquUXZTHmInOn-OFJToInrQOlqTIJD6ApdiYRMPIWzyzbzsvNhIe0bBAymX-S8kxvl_p-eY8z2t6s7-826_VytZw12_J2gVjrTbWo6lovVbms68Vmvdqsy9vb1d3dzGzLRbm8WSxvblbLcnkzV3c395sKyzXhBu9rXdwuqEVj53z_mftwmInpbzeLu3Ixs1iRjXKjLEu-L2bBsxWunmZhK5emqj9EvlWamOJ1m2SSlbvom9dWT_CHdLH398ViufvohvhDpfJsc7kWvjG7WR_s9u_c8-7Kxf8DAAD__4_-K-8">