[libcxx-commits] [libcxx] [libc++][NFC] re-order availability mapping to `_LIBCPP_INTRODUCED_IN_LLVM_{N}` (PR #210694)

[via libcxx-commits]

llvmorg-github-actions[bot] wrote:


<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-libcxx

Author: h-vetinari

<details>
<summary>Changes</summary>

Noticed that the new additions (from 16f692338cf41c29774e13f96856f040923f5d2c & 8a531c3608c722ad529be448d6ecef06ba107228) were placed rather randomly. Put the mapping back to reverse chronological order, c.f. 783fd2f9d583850ecacdf93cd65f903b64d0cf4d

---
Full diff: https://github.com/llvm/llvm-project/pull/210694.diff


1 Files Affected:

- (modified) libcxx/include/__configuration/availability.h (+12-12) 


``````````diff
diff --git a/libcxx/include/__configuration/availability.h b/libcxx/include/__configuration/availability.h
index 1fbd87ba52a64..0709deff47ea6 100644
--- a/libcxx/include/__configuration/availability.h
+++ b/libcxx/include/__configuration/availability.h
@@ -239,6 +239,18 @@
 
 #endif
 
+// This determines whether we assume that the internal std::__bad_variant_access_with_msg class
+// (which carries a message describing the cause of the failure in bad_variant_access::what())
+// provides a key function in the dylib. This allows centralizing its vtable and typeinfo instead
+// of having all TUs provide a weak definition that then gets deduplicated. When it is not available
+// in the dylib, what() is defined inline instead, so the descriptive message is provided regardless.
+#define _LIBCPP_AVAILABILITY_HAS_BAD_VARIANT_ACCESS_WITH_MSG_KEY_FUNCTION _LIBCPP_INTRODUCED_IN_LLVM_23
+// No attribute, since we've had bad_variant_access in the headers before
+
+// Controls whether the implementation for text_encoding::environment() is available
+#define _LIBCPP_AVAILABILITY_HAS_TEXT_ENCODING_ENVIRONMENT _LIBCPP_INTRODUCED_IN_LLVM_23
+#define _LIBCPP_AVAILABILITY_TEXT_ENCODING_ENVIRONMENT _LIBCPP_INTRODUCED_IN_LLVM_23_ATTRIBUTE
+
 // This controls the availability of new implementation of std::atomic's
 // wait, notify_one and notify_all. The new implementation uses
 // the native atomic wait/notify operations on platforms that support them
@@ -256,14 +268,6 @@
 #define _LIBCPP_AVAILABILITY_HAS_BAD_FUNCTION_CALL_GOOD_WHAT_MESSAGE _LIBCPP_INTRODUCED_IN_LLVM_21
 // No attribute, since we've had bad_function_call::what() in the headers before
 
-// This determines whether we assume that the internal std::__bad_variant_access_with_msg class
-// (which carries a message describing the cause of the failure in bad_variant_access::what())
-// provides a key function in the dylib. This allows centralizing its vtable and typeinfo instead
-// of having all TUs provide a weak definition that then gets deduplicated. When it is not available
-// in the dylib, what() is defined inline instead, so the descriptive message is provided regardless.
-#define _LIBCPP_AVAILABILITY_HAS_BAD_VARIANT_ACCESS_WITH_MSG_KEY_FUNCTION _LIBCPP_INTRODUCED_IN_LLVM_23
-// No attribute, since we've had bad_variant_access in the headers before
-
 // This controls the availability of floating-point std::from_chars functions.
 // These overloads were added later than the integer overloads.
 #define _LIBCPP_AVAILABILITY_HAS_FROM_CHARS_FLOATING_POINT _LIBCPP_INTRODUCED_IN_LLVM_20
@@ -323,10 +327,6 @@
 #  define _LIBCPP_AVAILABILITY_HAS_ADDITIONAL_IOSTREAM_EXPLICIT_INSTANTIATIONS_1 0
 #endif
 
-// Controls whether the implementation for text_encoding::environment() is available
-#define _LIBCPP_AVAILABILITY_HAS_TEXT_ENCODING_ENVIRONMENT _LIBCPP_INTRODUCED_IN_LLVM_23
-#define _LIBCPP_AVAILABILITY_TEXT_ENCODING_ENVIRONMENT _LIBCPP_INTRODUCED_IN_LLVM_23_ATTRIBUTE
-
 // Only define a bunch of symbols in the dylib if we need to be compatible with LLVM 7 headers or older
 #  if defined(_LIBCPP_BUILDING_LIBRARY) && _LIBCPP_AVAILABILITY_MINIMUM_HEADER_VERSION < 8
 #    define _LIBCPP_HIDE_FROM_ABI_SINCE_LLVM8

``````````

</details>


https://github.com/llvm/llvm-project/pull/210694