add __forceinline to std::unreachable instead of inline

[Igor Zhukov (fsb4000)]

Co-authored-by: Alexander Bessonov alexbav@hhdsoftware.com

From #3051

And we already use __forceinline there:

STL/stl/inc/xcharconv_ryu.h

Line 166 in febb643

_NODISCARD __forceinline uint64_t __ryu_umul128(const uint64_t __a, const uint64_t __b, uint64_t* const __productHi) {

[nicole mazzuca (strega-nil-ms)]

This looks extremely reasonable to me, personally - we know that MSVC does not consider [[noreturn]] functions for inlining unless they're marked with __forceinline. I would like to see what the opinions of the other maintainers are, though.

[nicole mazzuca (strega-nil-ms)]

If the rest of the team thinks this is reasonable, this is obviously the correct way to implement this.

[Stephan T. Lavavej (StephanTLavavej)]

I agree with nicole mazzuca (@strega-nil-ms), and Alex Bessonov (@AlexBAV)'s codegen example https://godbolt.org/z/a9d33hc5b shows that this makes a difference for /O2. In __ryu_umul128, the use of __forceinline was a compiler workaround (marked TRANSITION), but here the compiler's behavior regarding [[noreturn]] is reasonable and so __forceinline is also a reasonable perma-workaround. (The Ryu/charconv usage proves that __forceinline shouldn't cause other issues due to its non-Standardness.)

[Stephan T. Lavavej (StephanTLavavej)]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[Stephan T. Lavavej (StephanTLavavej)]

Thanks for improving the STL's performance to previously unreachable levels! 📈 🚀 😹

[Alex Bessonov (AlexBAV)]

Thanks for improving the STL's performance to previously unreachable levels! 📈 🚀 😹

You're always welcome :)