[libcxx] [llvm] [libc++][math][c++17] P0226R1 - Mathematical Special Functions: infra + `std::assoc_laguerre` (PR #205649)

[via llvm-commits]

================
@@ -0,0 +1,161 @@
+//===----------------------------------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include <__cmath/special_functions.h>
+#include <__config>
+#include <cerrno>
+#include <cfenv>
+#include <cmath>
+#include <limits>
+
+// GCC defines __STDCPP_FLOATnn_T__ whenever the _Floatnn extended types exist at the
+// language level, independent of the standard library. libc++ currently ships no
+// <stdfloat>, so std::floatnn_t is never declared -- but Boost.Math keys its
+// std::floatnn_t overloads off these macros and would reference the missing types.
+// Suppress those overloads while <stdfloat> is unavailable. The __has_include guard is
+// the same condition Boost uses to include <stdfloat>, so this workaround disables itself
+// automatically once libc++ provides the header (the overloads then light up on their own
+// -- no manual re-enable needed here).
+#if !__has_include(<stdfloat>)
+#  undef __STDCPP_FLOAT16_T__
+#  undef __STDCPP_FLOAT32_T__
+#  undef __STDCPP_FLOAT64_T__
+#  undef __STDCPP_FLOAT128_T__
+#  undef __STDCPP_BFLOAT16_T__
+#endif
+
+// Boost.Math detects thread support via __has_include(<thread>/<mutex>/...), but libc++
+// ships those headers even when threads are disabled (_LIBCPP_HAS_THREADS == 0), so the
+// detection wrongly enables std::mutex use and breaks on no-thread targets (e.g. picolibc).
+// Tell Boost there are no threads; lazy-init tables don't need locking without threads.
+#if !_LIBCPP_HAS_THREADS
+#  define BOOST_MATH_DISABLE_THREADS
+#endif
+
+#define BOOST_MATH_NO_EXCEPTIONS
----------------
PaulXiCao wrote:

Yes. AFAIK all of our public functions are `noexcept`. We already use boost policies that map errors to errno instead of exceptions. This is just explicit and also makes boost check that we really do not throw any exceptions.

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