We've added _LIBCPP_HIDE_FROM_ABI to a lot of functions lately, because we now have a clang-tidy check that makes sure we add it to all the functions that need it. Because of that a lot of functions are marked [[gnu::always_inline]] with GCC, which results in GCC taking a lot longer to compile with libc++. This patch introduces _LIBCPP_HIDE_FROM_ABI_NAMESPACE, which fulfills the same purpose as adding _LIBCPP_HIDE_FROM_ABI to the functions inside it. It also avoids a lot of _LIBCPP_HIDE_FROM_ABI annotations, since it can be used for a lot of functions, instead of having to mark every single one. Structs and ABI-sensitive functions should not be placed inside this namespace, since the ABI will change with bumping the libc++ version macro. To avoid having structs inside the namespace or having functions unnecessarily marked _LIBCPP_HIDE_FROM_ABI, this patch also adds clang-tidy checks for these cases.
I'm not convinced this is an improvement.
There are restrictions to what can be placed in the "namespace". It also removes the attribute from the reader. To know whether a function is hidden from the ABI you need to look at the "namespace" the object is placed in and for member functions you still need use the macro.
For the small example the readability remains the same, but in the end it doesn't save a lot of code.
Are structs/classes/unions the only exception, what about enum/enum class?
When doing this the visibly documentation needs to be updated too.
Maybe it would be good to discuss this patch on Discord.
With regard to gcc's always_inline, since we are using _LIBCPP_HIDE_FROM_ABI everywhere now, would it cause this problem to gcc?
I don't know if it errors out at any point, but code bloat at -O0 is definitely a problem.
major, minor, patch. Do you have a better suggestion?
I would use the magic number 8 and comment describing why it's 8.