[libc++] Make everything in namespace std have default type visibility and hidden visibility and remove _LIBCPP_ENUM_VIS

[philnik]

Summary

This avoids having to add _LIBCPP_ENUM_VIS, since that is handled through type_visibility and GCC always makes the visibility of enums default. It also fixes and missing _LIBCPP_EXPORTED_FROM_ABI on classes when using Clang.

[ldionne]

libcxx/docs/DesignDocs/VisibilityMacros.rst

1

We need to document the idea behind this change in this documentation.

libcxx/include/__config

716

Can you add a comment explaining why this is necessary? IIUC, this is only necessary because GCC doesn't implement __type_visibility__ -- otherwise we would be able to drop this macro entirely.

799–801

This change will have the following non-trivial effects:

1. Everything in namespace std will now have default type-visibility. Previously, only the things marked with a visibility macro would get that treatment. Why is that okay? Can this bite users or us?
2. Everything in namespace std will now have hidden visibility unless overridden. Previously, that was our intent, but we might not have been doing it 100% consistently so this might actually have an impact on what symbols become exported when folks use our headers. Do we have an idea of which symbols this impacts, and have you thought about the potential user impact of this?

Let's document that in the commit message (and also in a release note if we foresee user impact).

[philnik]

Address comments

libcxx/include/__config

799–801

1. Every public type is supposed to have default type visibility to make it possible to throw things across library boundaries and have RTTI work (that is required for e.g. std::any). While the usefulness is questionable for many types (e.g. remove_const and friends), it is technically allowed to get RTTI for all types. For library-internal types, it should be fine, since RTTI won't ever get actually generated for them, making it irrelevant what visibility the symbols have. This will be a user-visible change insofar as it will fix any missing visibility attributes on classes, but I don't think that will have a big impact.

2. This should™ only impact global variables and functions which don't have any kind of visibility annotation. Given that almost all functions already have visibility annotations, this shouldn't make much of an impact there. The global variables will be duplicated across libraries with this change, but I don't think that's much of a problem. This should only be noticeable by checking the address of the variable, since any global variables I'm aware of are constexpr or at least const. Almost nobody does that, since it's not interesting other than checking for strict conformance, so I wouldn't consider that much of a problem either. This also already happens when -fvisibility=hidden is used, which is the case for people who care about their ABI surface.

[ldionne]

libcxx/include/__config

799–801

(2) means in particular that we'll give hidden visibility to global objects like is_const_v & friends. This means that we no longer export them from our client's ABI surface by default.

This is great since weak symbols at ABI boundaries are costly (load times), however that is technically a behavior change. If we make this change, I would like us to pin that behavior down and also probably get some sort of wording into the standard that says "these _v objects are not guaranteed to have a fixed address". It's obviously the intent but we'd need to be explicit about this.

Also, whenever we do this, let's try to do it early in a release cycle to catch issues early on.

[ldionne]

Trying to summarize our long discussion just now: I think there are two changes in here.

1. Apply type_visibility(default) on namespace std. This fixes an existing issue where we most likely are missing some type_visibility(default) on types, which means that some types might not work properly with std::any and anything related to RTTI, basically (which includes exceptions). This change does have a change of behavior, but it makes things "less strict" in a way, i.e. more code will work than today. Applying type_visibility(default) on the namespace also has the side effect that _LIBCPP_ENUM_VIS is not required anymore, so we can clean that up if we want (potentially even as a separate patch, IDK).
2. The second change is applying _LIBCPP_HIDDEN on namespace std. This will have the effect that we stop exporting some functions that we basically forgot to mark as hidden, which we arguably want. However, we also have to decide what to do with a bunch of other entities, such as the _v variable templates. For those, we have to decide whether we want to keep exporting them or not, and that requires guidance from the Committee (especially since WG21 went through the trouble of making these inline variables). If the conclusion is that we need to keep exporting them, then we can either drop this change, or mark namespace std as hidden but then also apply an explicit default visibility to the things we want to export. Those are different approaches and we can discuss them on a patch that tackles just that side of the problem. Also note that we don't necessarily have to wait for WG21 to apply hidden to the namespace. The WG21 guidance is only required to know whether we could drop the manual EXPORT_FROM_ABI annotation from these _v entities if we made namespace std have hidden visibility.

[philnik]

• Rebase
• Only add type_visibility("default") to the namespace

[ldionne]

This LGTM with passing CI, updated commit message and the release note.

For most people who compile with -fvisibility=default (or nothing at all), this is a no-op since everything in the library already had default visibility. For users who build with -fvisibility=hidden, there used to be a bunch of types that we forgot to apply type_visibility(default) or visibility(default) to, and those would previously be hidden. After this change, their type_visibility would become default (as it should) on Clang (but not on GCC).

libcxx/.clang-format

25

The commit message needs to be updated!

libcxx/docs/DesignDocs/VisibilityMacros.rst

3

Release note:

This release of libc++ added missing visibility annotations on some types in the library. Users compiling with -fvisbility=hidden may notice that additional type infos from libc++ are being exported from their ABI. This is the correct behavior in almost all cases since exporting the RTTI is required for these types to work properly with dynamic_cast, exceptions and other mechanisms. However, if you intend to use libc++ purely as an internal implementation detail (i.e. you use libc++ as a static archive and never export libc++ symbols from your ABI) and you notice changes to your exported symbols list, then this means that you were not properly preventing libc++ symbols from being part of your ABI.

[philnik]

Address comments

[EricWF]

In D153658#4599282, @ldionne wrote:

This LGTM with passing CI, updated commit message and the release note.

For most people who compile with -fvisibility=default (or nothing at all), this is a no-op since everything in the library already had default visibility. For users who build with -fvisibility=hidden, there used to be a bunch of types that we forgot to apply type_visibility(default) or visibility(default) to, and those would previously be hidden. After this change, their type_visibility would become default (as it should) on Clang (but not on GCC).

I don't think this change was thought through.

• This is a major issue for people who build and ship their own shared libraries.
• Iterating over long symbol lists is an issue, and can cause really yucky hash collisions in the dynamic linker loader.
• This isn't just about types. It's about functions. And now every single weak function template that's instantiated as part of a users library build

Based on the comments in this change, it's not clear to me you considered the most common use cases for -fvisibility=hidden.
Could you explain to me what affect you believe this change has on other shared libraries?

libcxx/docs/ReleaseNotes/18.rst

82 ↗

(On Diff #551791)

A lot of this is incorrect.

-fvisibility-hidden is for when your

[EricWF]

libcxx/docs/ReleaseNotes/18.rst

82 ↗

(On Diff #551791)

-fvisibility=default causes all symbols to be exported from any dylib they're emitted in (and for templates, that's every TU).

Dynamic cast and friends only matter when you're trying to do it across shared library boundaries, which is very rare. Otherwise having duplicate vtables/type infos isn't a big deal.

Further, I don't understand what ". However, if you intend to use libc++ purely as an

internal implementation detail (i.e. you use libc++ as a static archive and never export libc++ symbols from your ABI)
and you notice changes to your exported symbols list, then this means that you were not properly preventing libc++
symbols from being part of your ABI." is actually talking about.

[EricWF]

In D153658#4457143, @philnik wrote:

Address comments
This should™ only impact global variables and functions which don't have any kind of visibility annotation. Given that almost all functions already have visibility annotations, this shouldn't make much of an impact there. The global variables will be duplicated across libraries with this change, but I don't think that's much of a problem. This should only be noticeable by checking the address of the variable, since any global variables I'm aware of are constexpr or at least const. Almost nobody does that, since it's not interesting other than checking for strict conformance, so I wouldn't consider that much of a problem either. This also already happens when -fvisibility=hidden is used, which is the case for people who care about their ABI surface.

This is easy to test. Was that done?

[ldionne]

In D153658#4612457, @EricWF wrote:

In D153658#4599282, @ldionne wrote:

This LGTM with passing CI, updated commit message and the release note.

For most people who compile with -fvisibility=default (or nothing at all), this is a no-op since everything in the library already had default visibility. For users who build with -fvisibility=hidden, there used to be a bunch of types that we forgot to apply type_visibility(default) or visibility(default) to, and those would previously be hidden. After this change, their type_visibility would become default (as it should) on Clang (but not on GCC).

I don't think this change was thought through.

[...]

Based on the comments in this change, it's not clear to me you considered the most common use cases for -fvisibility=hidden.

We did definitely think through this change and consider the effects this would have on shared libraries. It's not impossible that we made a mistake somewhere, but at least we discussed it for hours and I still think that this patch is definitely correct (and the behavior we want). Let's talk to figure this out.

• This is a major issue for people who build and ship their own shared libraries.

I think this is actually the behavior they want/need for their code to be correct, see below.

• Iterating over long symbol lists is an issue, and can cause really yucky hash collisions in the dynamic linker loader.
• This isn't just about types. It's about functions. And now every single weak function template that's instantiated as part of a users library build

__type_visibility__ only affects the visibility of the RTTI and the vtable of the type, doesn't it? I don't think it has any effect on the functions inside the namespace (otherwise yes this would be a completely different can of worms). I checked on Godbolt and it seemed to confirm this: https://godbolt.org/z/z315e79cf

Could you explain to me what affect you believe this change has on other shared libraries?

As explained in https://reviews.llvm.org/D153658#4599282:

For most people who compile with -fvisibility=default (or nothing at all), this is a no-op since everything in the library already had default visibility. For users who build with -fvisibility=hidden, there used to be a bunch of types that we forgot to apply type_visibility(default) or visibility(default) to, and those would previously be hidden. After this change, their type_visibility would become default (as it should) on Clang (but not on GCC).

I think we agree that this is a no-op for people building with nothing at all or with -fvisibility=default, since they already export everything.

Let's consider users of -fvisibility=hidden (let's say they are building a shared library). For those, there used to be a bunch of types that we did not apply any visibility attribute to (I'll argue that this is just an oversight). As a result, the RTTI of these types would not be exported from the user's dylib. For example, let's say someone had filter_view<V, Pred> view{...} in their code. Since we don't have any visibility markup on that type (oops, I think that one is on me), that type's vtable+RTTI would get hidden visibility if people are building with -fvisibility=hidden. Do we agree on that?

If so, then do we also agree that if they did something like throw view; from within the dylib boundary and then someone tried to catch it as catch (std::filter_view<V, Pred>) from outside the dylib boundary, it wouldn't work? That's because the RTTI attached to the filter_view is local to the -fvisibility=hidden dylib, and it's never exported from it. This shouldn't be a common use case, however something much more common would be e.g. passing a std::any containing a std::filter_view across an ABI boundary built with -fvisibility=hidden and then trying to retrieve it on the other side, or anything else that relates to RTTI.

This is basically a bug, right? If we used _LIBCPP_TEMPLATE_VIS and the other _FOO_VIS with 100% consistency, this would not be an issue but then applying __type_visibility__ to the namespace would be a no-op. But since we don't apply _FOO_VIS with 100% consistency, this basically fixes a bug where some types have incorrect visibility. Yes, it will slightly increase the number of symbols exported on dylib boundaries, but the symbols that are newly exported are going to be vtables/RTTIs of types that should always have been exported for correctness.

Let's see where/if we actually disagree or if I said something untrue above. We definitely considered the issue very closely and actually spent hours discussing this, and I explicitly requested to delay this change to after the release (and to land it early in the 18 release cycle) because I know how tricky these types of changes can be.

[EricWF]

I have to apologize for my previous comment.

When I was initially testing this change, I made some unknown mistake which make it appear as though there had been a 3x symbol increase in a test shared library.
However, when I went to reproduce, I couldn't replicate the result and indeed there was almost no movement in the amount of symbols.

I'm sorry. I spoke too soon and too strongly. I will work to improve my communication .

libcxx/.clang-format

AttributeMacros: [
                   '_ALIGNAS_TYPE',
                   '_ALIGNAS',
                   '_LIBCPP_ALIGNOF',
                   '_LIBCPP_ALWAYS_INLINE',
                   '_LIBCPP_CONSTEXPR_SINCE_CXX14',
                   '_LIBCPP_CONSTEXPR_SINCE_CXX17',
                   '_LIBCPP_CONSTEXPR_SINCE_CXX20',
                   '_LIBCPP_CONSTEXPR_SINCE_CXX23',
                   '_LIBCPP_CONSTEXPR',
                   '_LIBCPP_CONSTINIT',
                   '_LIBCPP_DEPRECATED_IN_CXX11',
                   '_LIBCPP_DEPRECATED_IN_CXX14',
                   '_LIBCPP_DEPRECATED_IN_CXX17',
                   '_LIBCPP_DEPRECATED_IN_CXX20',
                   '_LIBCPP_DEPRECATED',
                   '_LIBCPP_DISABLE_EXTENTSION_WARNING',
-                  '_LIBCPP_ENUM_VIS',
                   '_LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION',
                   '_LIBCPP_EXPORTED_FROM_ABI',
                   '_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS',
                   '_LIBCPP_FALLTHROUGH',
                   '_LIBCPP_HIDDEN',
                   '_LIBCPP_HIDE_FROM_ABI_AFTER_V1',
                   '_LIBCPP_HIDE_FROM_ABI',
                   '_LIBCPP_INLINE_VISIBILITY',

libcxx/docs/DesignDocs/VisibilityMacros.rst

 ========================
 Symbol Visibility Macros
 ========================
 
 .. contents::
    :local:
 
 .. _visibility-macros:
 
 Overview
 ========
 
 Libc++ uses various "visibility" macros in order to provide a stable ABI in
 both the library and the headers. These macros work by changing the
 visibility and inlining characteristics of the symbols they are applied to.
 
+The std namespace also has visibility attributes applied to avoid having to
+add visibility macros in as many places. Namespace std has default
+type_visibility to export RTTI and other type-specific information. Note that
+type_visibility is only supported by Clang, so this doesn't replace
+type-specific attributes. The only exception are enums, which GCC always gives
+default visibility, thus removing the need for any annotations.
+
 Visibility Macros
 =================
 
 **_LIBCPP_HIDDEN**
   Mark a symbol as hidden so it will not be exported from shared libraries.
 
 **_LIBCPP_EXPORTED_FROM_ABI**
   Mark a symbol as being part of our ABI. This includes functions that are part
**_LIBCPP_TEMPLATE_VIS**
 
   **GCC Behavior**: GCC does not support Clang's `type_visibility(...)`
   attribute. With GCC the `visibility(...)` attribute is used and member
   functions are affected.
 
   **Windows Behavior**: DLLs do not support dllimport/export on class templates.
   The macro has an empty definition on this platform.
 
-
-**_LIBCPP_ENUM_VIS**
-  Mark the typeinfo of an enum as having default visibility. This attribute
-  should be applied to all enum declarations.
-
-  **Windows Behavior**: DLLs do not support importing or exporting enumeration
-  typeinfo. The macro has an empty definition on this platform.
-
-  **GCC Behavior**: GCC un-hides the typeinfo for enumerations by default, even
-  if `-fvisibility=hidden` is specified. Additionally applying a visibility
-  attribute to an enum class results in a warning. The macro has an empty
-  definition with GCC.
-
 **_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS**
   Mark the member functions, typeinfo, and vtable of the type named in
   an extern template declaration as being exported by the libc++ library.
   This attribute must be specified on all extern class template declarations.
 
   This macro is used to override the `_LIBCPP_TEMPLATE_VIS` attribute
   specified on the primary template and to export the member functions produced
   by the explicit instantiation in the dylib.

libcxx/include/__charconv/chars_format.h

 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if _LIBCPP_STD_VER >= 17
 
-enum class _LIBCPP_ENUM_VIS chars_format { scientific = 0x1, fixed = 0x2, hex = 0x4, general = fixed | scientific };
+enum class chars_format { scientific = 0x1, fixed = 0x2, hex = 0x4, general = fixed | scientific };
 
 inline _LIBCPP_HIDE_FROM_ABI constexpr chars_format operator~(chars_format __x) {
   return chars_format(~std::__to_underlying(__x));
 }
 
 inline _LIBCPP_HIDE_FROM_ABI constexpr chars_format operator&(chars_format __x, chars_format __y) {
   return chars_format(std::__to_underlying(__x) & std::__to_underlying(__y));
 }

libcxx/include/__compare/ordering.h

 #  pragma GCC system_header
 #endif
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 #if _LIBCPP_STD_VER >= 20
 
 // exposition only
-enum class _LIBCPP_ENUM_VIS _OrdResult : signed char {
+enum class _OrdResult : signed char {
   __less = -1,
   __equiv = 0,
   __greater = 1
 };
 
-enum class _LIBCPP_ENUM_VIS _NCmpResult : signed char {
+enum class _NCmpResult : signed char {
   __unordered = -127
 };
 
 class partial_ordering;
 class weak_ordering;
 class strong_ordering;
 
 template<class _Tp, class... _Args>

libcxx/include/__config

 #      define _LIBCPP_OVERRIDABLE_FUNC_VIS
 #      define _LIBCPP_EXPORTED_FROM_ABI __declspec(dllimport)
 #    endif
 
 #    define _LIBCPP_HIDDEN
 #    define _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
 #    define _LIBCPP_TEMPLATE_VIS
 #    define _LIBCPP_TEMPLATE_DATA_VIS
-#    define _LIBCPP_ENUM_VIS
 
 #  else
 
 #    if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 #      define _LIBCPP_VISIBILITY(vis) __attribute__((__visibility__(vis)))
 #    else
 #      define _LIBCPP_VISIBILITY(vis)
 #    endif

 
 #    if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 // The inline should be removed once PR32114 is resolved
 #      define _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS inline _LIBCPP_HIDDEN
 #    else
 #      define _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
 #    endif
 
-#    if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
-#      if __has_attribute(__type_visibility__)
-#        define _LIBCPP_TEMPLATE_VIS __attribute__((__type_visibility__("default")))
-#      else
-#        define _LIBCPP_TEMPLATE_VIS __attribute__((__visibility__("default")))
-#      endif
+// GCC doesn't support the type_visibility attribute, so we have to keep the visibility attribute on templates
+#    if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && !__has_attribute(__type_visibility__)
+#      define _LIBCPP_TEMPLATE_VIS __attribute__((__visibility__("default")))
 #    else
 #      define _LIBCPP_TEMPLATE_VIS
 #    endif
 
 #    if !defined(_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS) && __has_attribute(__type_visibility__)
-#      define _LIBCPP_ENUM_VIS __attribute__((__type_visibility__("default")))
+#      define _LIBCPP_TYPE_VISIBILITY_DEFAULT __attribute__((__type_visibility__("default")))
 #    else
-#      define _LIBCPP_ENUM_VIS
+#      define _LIBCPP_TYPE_VISIBILITY_DEFAULT
 #    endif
 
 #  endif // defined(_LIBCPP_OBJECT_FORMAT_COFF)
 
 #  if __has_attribute(exclude_from_explicit_instantiation)
 #    define _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION __attribute__((__exclude_from_explicit_instantiation__))
 #  else
 // Try to approximate the effect of exclude_from_explicit_instantiation

 #    define _LIBCPP_HIDE_FROM_ABI_AFTER_V1 _LIBCPP_HIDE_FROM_ABI
 #  endif
 
 // Just so we can migrate to the new macros gradually.
 #  define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI
 
 // Inline namespaces are available in Clang/GCC/MSVC regardless of C++ dialect.
 // clang-format off
-#  define _LIBCPP_BEGIN_NAMESPACE_STD namespace std { inline namespace _LIBCPP_ABI_NAMESPACE {
+#  define _LIBCPP_BEGIN_NAMESPACE_STD namespace _LIBCPP_TYPE_VISIBILITY_DEFAULT std {                                  \
+                               inline namespace _LIBCPP_ABI_NAMESPACE {
 #  define _LIBCPP_END_NAMESPACE_STD }}
 #  define _VSTD std
 
 _LIBCPP_BEGIN_NAMESPACE_STD _LIBCPP_END_NAMESPACE_STD
 
 #  if _LIBCPP_STD_VER >= 17
 #    define _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM                                                                         \
        _LIBCPP_BEGIN_NAMESPACE_STD inline namespace __fs { namespace filesystem {
 #  else
#    define _LIBCPP_DECLARE_STRONG_ENUM_EPILOG(x)                                                                      \
       __lx __v_;                                                                                                       \
       _LIBCPP_INLINE_VISIBILITY x(__lx __v) : __v_(__v) {}                                                             \
       _LIBCPP_INLINE_VISIBILITY explicit x(int __v) : __v_(static_cast<__lx>(__v)) {}                                  \
       _LIBCPP_INLINE_VISIBILITY operator int() const { return __v_; }                                                  \
       };
 // clang-format on
 
 #  else // _LIBCPP_CXX03_LANG
-#    define _LIBCPP_DECLARE_STRONG_ENUM(x) enum class _LIBCPP_ENUM_VIS x
+#    define _LIBCPP_DECLARE_STRONG_ENUM(x) enum class x
 #    define _LIBCPP_DECLARE_STRONG_ENUM_EPILOG(x)
 #  endif // _LIBCPP_CXX03_LANG
 
 #  if defined(__APPLE__) || defined(__FreeBSD__) || defined(_LIBCPP_MSVCRT_LIKE) || defined(__NetBSD__)
 #    define _LIBCPP_LOCALE__L_EXTENSIONS 1
 #  endif
 
 #  ifdef __FreeBSD__

libcxx/include/__filesystem/copy_options.h

 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 #ifndef _LIBCPP_CXX03_LANG
 
 _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
 
-enum class _LIBCPP_ENUM_VIS copy_options : unsigned short {
+enum class copy_options : unsigned short {
   none = 0,
   skip_existing = 1,
   overwrite_existing = 2,
   update_existing = 4,
   recursive = 8,
   copy_symlinks = 16,
   skip_symlinks = 32,
   directories_only = 64,

libcxx/include/__filesystem/directory_options.h

 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 #ifndef _LIBCPP_CXX03_LANG
 
 _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
 
-enum class _LIBCPP_ENUM_VIS directory_options : unsigned char {
+enum class directory_options : unsigned char {
   none = 0,
   follow_directory_symlink = 1,
   skip_permission_denied = 2
 };
 
 _LIBCPP_INLINE_VISIBILITY
 inline constexpr directory_options operator&(directory_options __lhs,
                                              directory_options __rhs) {

libcxx/include/__filesystem/file_type.h

 #endif
 
 #ifndef _LIBCPP_CXX03_LANG
 
 _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
 
 // On Windows, the library never identifies files as block, character, fifo
 // or socket.
-enum class _LIBCPP_ENUM_VIS file_type : signed char {
+enum class file_type : signed char {
   none = 0,
   not_found = -1,
   regular = 1,
   directory = 2,
   symlink = 3,
   block = 4,
   character = 5,
   fifo = 6,

libcxx/include/__filesystem/path.h

#if defined(_LIBCPP_WIN32API)
   static constexpr value_type preferred_separator = L'\\';
 #else
   typedef char value_type;
   static constexpr value_type preferred_separator = '/';
 #endif
   typedef basic_string<value_type> string_type;
   typedef basic_string_view<value_type> __string_view;
 
-  enum _LIBCPP_ENUM_VIS format : unsigned char {
+  enum format : unsigned char {
     auto_format,
     native_format,
     generic_format
   };
 
   // constructors and destructor
   _LIBCPP_HIDE_FROM_ABI path() noexcept {}
   _LIBCPP_HIDE_FROM_ABI path(const path& __p) : __pn_(__p.__pn_) {}

libcxx/include/__filesystem/perm_options.h

 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #  pragma GCC system_header
 #endif
 
 #ifndef _LIBCPP_CXX03_LANG
 
 _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
 
-enum class _LIBCPP_ENUM_VIS perm_options : unsigned char {
+enum class perm_options : unsigned char {
   replace = 1,
   add = 2,
   remove = 4,
   nofollow = 8
 };
 
 _LIBCPP_INLINE_VISIBILITY
 inline constexpr perm_options operator&(perm_options __lhs, perm_options __rhs) {

libcxx/include/__filesystem/perms.h

 #ifndef _LIBCPP_CXX03_LANG
 
 _LIBCPP_BEGIN_NAMESPACE_FILESYSTEM
 
 // On Windows, these permission bits map to one single readonly flag per
 // file, and the executable bit is always returned as set. When setting
 // permissions, as long as the write bit is set for either owner, group or
 // others, the readonly flag is cleared.
-enum class _LIBCPP_ENUM_VIS perms : unsigned {
+enum class perms : unsigned {
   none = 0,
 
   owner_read = 0400,
   owner_write = 0200,
   owner_exec = 0100,
   owner_all = 0700,
 
   group_read = 040,

libcxx/include/__format/format_arg.h

 /// ABI break. The packed type is 64-bit so this reduces the maximum number of
 /// packed elements from 16 to 12.
 ///
 /// @note Some members of this enum are an extension. These extensions need
 /// special behaviour in visit_format_arg. There they need to be wrapped in a
 /// handle to satisfy the user observable behaviour. The internal function
 /// __visit_format_arg doesn't do this wrapping. So in the format functions
 /// this function is used to avoid unneeded overhead.
-enum class _LIBCPP_ENUM_VIS __arg_t : uint8_t {
+enum class __arg_t : uint8_t {
   __none,
   __boolean,
   __char_type,
   __int,
   __long_long,
   __i128, // extension
   __unsigned,
   __unsigned_long_long,

libcxx/include/__format/parser_std_format_spec.h

 inline constexpr __fields __fields_pointer{.__zero_padding_ = true, .__type_ = true, .__consume_all_ = true};
 
 #  if _LIBCPP_STD_VER >= 23
 inline constexpr __fields __fields_tuple{.__use_range_fill_ = true, .__clear_brackets_ = true};
 inline constexpr __fields __fields_range{.__use_range_fill_ = true, .__clear_brackets_ = true};
 inline constexpr __fields __fields_fill_align_width{};
 #  endif
 
-enum class _LIBCPP_ENUM_VIS __alignment : uint8_t {
+enum class __alignment : uint8_t {
   /// No alignment is set in the format string.
   __default,
   __left,
   __center,
   __right,
   __zero_padding
 };
 
-enum class _LIBCPP_ENUM_VIS __sign : uint8_t {
+enum class __sign : uint8_t {
   /// No sign is set in the format string.
   ///
   /// The sign isn't allowed for certain format-types. By using this value
   /// it's possible to detect whether or not the user explicitly set the sign
   /// flag. For formatting purposes it behaves the same as \ref __minus.
   __default,
   __minus,
   __plus,
   __space
 };
 
-enum class _LIBCPP_ENUM_VIS __type : uint8_t {
+enum class __type : uint8_t {
   __default = 0,
   __string,
   __binary_lower_case,
   __binary_upper_case,
   __octal,
   __decimal,
   __hexadecimal_lower_case,
   __hexadecimal_upper_case,

libcxx/include/__format/write_escaped.h

#    endif
   return true;
 }
 
 template <class _CharT>
 [[nodiscard]] _LIBCPP_HIDE_FROM_ABI constexpr char32_t __to_char32(_CharT __value) {
   return static_cast<make_unsigned_t<_CharT>>(__value);
 }
 
-enum class _LIBCPP_ENUM_VIS __escape_quotation_mark { __apostrophe, __double_quote };
+enum class __escape_quotation_mark { __apostrophe, __double_quote };
 
 // [format.string.escaped]/2
 template <class _CharT>
 [[nodiscard]] _LIBCPP_HIDE_FROM_ABI bool
 __is_escaped_sequence_written(basic_string<_CharT>& __str, char32_t __value, __escape_quotation_mark __mark) {
   // 2.2.1.1 - Mapped character in [tab:format.escape.sequences]
   switch (__value) {
   case _CharT('\t'):

libcxx/include/__fwd/subrange.h

 #if _LIBCPP_STD_VER >= 20
 
 #include <__iterator/concepts.h>
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
 namespace ranges {
 
-enum class _LIBCPP_ENUM_VIS subrange_kind : bool { unsized, sized };
+enum class subrange_kind : bool { unsized, sized };
 
 template <input_or_output_iterator _Iter, sentinel_for<_Iter> _Sent, subrange_kind _Kind>
   requires(_Kind == subrange_kind::sized || !sized_sentinel_for<_Sent, _Iter>)
 class _LIBCPP_TEMPLATE_VIS subrange;
 
 } // namespace ranges
 
 _LIBCPP_END_NAMESPACE_STD
 
 #endif // _LIBCPP_STD_VER >= 20
 
 #endif // _LIBCPP___FWD_SUBRANGE_H

libcxx/include/new

 #else
     _LIBCPP_VERBOSE_ABORT("bad_array_new_length was thrown in -fno-exceptions mode");
 #endif
 }
 
 #if !defined(_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION) && \
     !defined(_LIBCPP_ABI_VCRUNTIME)
 #ifndef _LIBCPP_CXX03_LANG
-enum class _LIBCPP_ENUM_VIS align_val_t : size_t { };
+enum class align_val_t : size_t { };
 #else
 enum align_val_t { __zero = 0, __max = (size_t)-1 };
 #endif
 #endif
 
 #if _LIBCPP_STD_VER >= 20
 // Enable the declaration even if the compiler doesn't support the language
 // feature.